This was responded to on the DNSEXT mailing list.
Sorry, but your question was accidentally attributed to Paul who
forwarded the message.
DNSEXT Archive: http://ops.ietf.org/lists/namedroppers/
-Doug
On Thu, 06 Aug 2009 06:51:24 +
Paul Vixie wrote:
> Christopher Morrow writes:
>
> > how does SCTP ensure against spoofed or reflected attacks?
>
> there is no server side protocol control block required in SCTP.
> someone sends you a "create association" request, you send back a
> "ok, her
>> doesn't the iphone has an app to decode qr-codes similar to the one
>> built into almost all keitai here in japan.
>>
>> http://en.wikipedia.org/wiki/QR_Code
>
> Yep. Called iMatrix. (There are probably others too)
Yes, that's one of the apps.
Anyway, as you can see this is just one exam
>> Have you seen the iphone decoding bar code into urls ?
>
> doesn't the iphone has an app to decode qr-codes similar to the one
> built into almost all keitai here in japan.
Yes, is not really new but it can decode QR, DataMatrix (same as used
for postage),
ShotCode and bar code. With the new ca
On 7-Aug-09, at 8:01 PM, Randy Bush wrote:
Have you seen the iphone decoding bar code into urls ?
doesn't the iphone has an app to decode qr-codes similar to the one
built into almost all keitai here in japan.
http://en.wikipedia.org/wiki/QR_Code
There are multiple (5+ at last count) iP
> doesn't the iphone has an app to decode qr-codes similar to the one
> built into almost all keitai here in japan.
>
> http://en.wikipedia.org/wiki/QR_Code
Yep. Called iMatrix. (There are probably others too)
> Have you seen the iphone decoding bar code into urls ?
doesn't the iphone has an app to decode qr-codes similar to the one
built into almost all keitai here in japan.
http://en.wikipedia.org/wiki/QR_Code
randy
On Thu, Aug 6, 2009 at 6:06 AM, Alexander Harrowell
wrote:
> 1) Authenticate the nameserver to the client (and so on up the chain to the
> root) in order to defeat the Kaminsky attack, man in the middle, IP-layer
> interference. (Are you who you say you are?)
DNSSEC fans will be quick to point o
On Thu, Aug 6, 2009 at 11:16 AM, Paul Vixie wrote:
> note, i went off-topic in my previous note, and i'll be answering florian
> on namedroppers@ since it's not operational. chris's note was operational:
>
>> Date: Thu, 6 Aug 2009 10:18:11 -0400
>> From: Christopher Morrow
>>
>> awesome, how does
On Thu, Aug 06, 2009 at 03:16:25PM +, Paul Vixie wrote:
> > ...: "Do loadbalancers, or loadbalanced deployments, deal with this
> > properly?" (loadbalancers like F5, citrix, radware, cisco, etc...)
>
> as far as i know, no loadbalancer understands SCTP today. if they can be
> made to pass SC
note, i went off-topic in my previous note, and i'll be answering florian
on namedroppers@ since it's not operational. chris's note was operational:
> Date: Thu, 6 Aug 2009 10:18:11 -0400
> From: Christopher Morrow
>
> awesome, how does that work with devices in the f-root-anycast design?
> (bo
On 8/5/09 7:05 PM, Naveen Nathan wrote:
On Wed, Aug 05, 2009 at 09:17:01PM -0400, John R. Levine wrote:
...
It seems to me that the situation is no worse than DNSSEC, since in both
cases the software at each hop needs to be aware of the security stuff, or
you fall back to plain unsigned DNS.
On Thu, Aug 6, 2009 at 2:51 AM, Paul Vixie wrote:
> Christopher Morrow writes:
>
>> how does SCTP ensure against spoofed or reflected attacks?
>
> there is no server side protocol control block required in SCTP. someone
> sends you a "create association" request, you send back a "ok, here's your
On Wed, 5 Aug 2009, Naveen Nathan wrote:
>
> I might misunderstand how dnscurve works, but it appears that dnscurve
> is far easier to deploy and get running.
Not really. There are multiple competing mature implementations of DNSSEC
and you won't be in a network of 1 if you deploy it.
Tony.
--
f
There are really two security problems here, which implies that two different
methods might be necessary:
1) Authenticate the nameserver to the client (and so on up the chain to the
root) in order to defeat the Kaminsky attack, man in the middle, IP-layer
interference. (Are you who you say you
On Thu, 6 Aug 2009, Florian Weimer wrote:
This doesn't seem possible with current SCTP because the heartbeat
rate quickly adds up and overloads servers further upstream. It
also does not work on UNIX-like system where processes are
short-lived and get a fresh stub resolver each time they are
* Naveen Nathan:
> I'll assume the cipher used for the lasting secret keys is interchangeable.
Last time I checked, even the current cryptographic algorithms weren't
specified. It's unlikely that there is an upgrade path (other than
stuffing yet another magic label into your name server names).
* John Levine:
> 3) Random case in queries, e.g. GooGLe.CoM
This does not work well without additional changes because google.com
can be spoofed with responses to 123352123.com (or even 123352123.).
Unbound strives to implement the necessary changes, some of which are
also required if you want t
* Paul Vixie:
> there is no server side protocol control block required in SCTP.
SCTP needs per-peer state for congestion control and retransmission.
> someone sends you a "create association" request, you send back a
> "ok, here's your cookie" and you're done until/unless they come back
> and s
* Douglas Otis:
> DNSSEC UDP will likely become problematic. This might be due to
> reflected attacks,
SCTP does not stop reflective attacks at the DNS level. To deal with
this issue, you need DNSSEC's denial of existence. The DNSSEC specs
currently doesn't allow you to stop these attacks dead
* Douglas Otis:
> Establishing SCTP as a preferred DNS transport offers a safe harbor
> for major ISPs.
SCTP is not a suitable transport for DNS, for several reasons:
Existing SCTP stacks are not particularly robust (far less than TCP).
The number of bugs still found in them is rather large.
On
Christopher Morrow writes:
> how does SCTP ensure against spoofed or reflected attacks?
there is no server side protocol control block required in SCTP. someone
sends you a "create association" request, you send back a "ok, here's your
cookie" and you're done until/unless they come back and say
Ben,
Thanks for the cogent comparison between the two security systems
for DNS.
> DNSCurve requires more CPU power on nameservers (for the more
> extensive crypto); DNSSEC requires more memory (for the additional
> DNSSEC payload).
This is only true for the initial (Elliptic Curve) Diffie-Hell
On Wed, Aug 5, 2009 at 10:05 PM, Naveen Nathan wrote:
> I might misunderstand how dnscurve works, but it appears that dnscurve
> is far easier to deploy and get running.
My understanding:
They really do different things. They also have different behaviors.
DNSCurve aims to secure the tran
ng time as far as I can
tell.
- S
-Original Message-
From: Naveen Nathan [mailto:nav...@calpop.com]
Sent: Wednesday, August 05, 2009 7:05 PM
To: John R. Levine
Cc: nanog@nanog.org
Subject: Re: dnscurve and DNS hardening, was Re: Dan Kaminsky
On Wed, Aug 05, 2009 at 09:17:01PM -0400, John
> -- Ben @ 209.85.221.52
Really?
farside.isc.org:marka {2} % telnet 209.85.221.52 25
Trying 209.85.221.52...
Connected to mail-qy0-f52.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP 26si8920387qyk.119
helo farside.isc.org
250 mx.google.com at your service
mail from:
250 2.1.0 OK
On Wed, Aug 05, 2009 at 09:17:01PM -0400, John R. Levine wrote:
> ...
>
> It seems to me that the situation is no worse than DNSSEC, since in both
> cases the software at each hop needs to be aware of the security stuff, or
> you fall back to plain unsigned DNS.
I might misunderstand how dnscurv
On Wed, Aug 5, 2009 at 6:53 PM, Douglas Otis wrote:
> On 8/5/09 2:49 PM, Christopher Morrow wrote:
>>
>> and state-management seems like it won't be too much of a problem on
>> that dns server... wait, yes it will.
>
> DNSSEC UDP will likely become problematic. This might be due to reflected
> att
In message , "John R. Levine"
writes:
> >>> http://dnscurve.org/crypto.html, which is always brought up, but
> >>> never seems to solve the problems mentioned.
>
> > As I understand it, dnscurve protects transmissions, not objects.
> > That's not the way DNS operates today, what with N levels of
On Wed, Aug 5, 2009 at 8:40 PM, James R.
Cutler wrote:
>>> (2) Saying "type our name into $SERVICE", where $SERVICE is some
>>> popular website that most people trust (like Facebook or whatever),
>>> and has come up with a workable system for disambiguation.
>
> I can only hope that those who belie
http://dnscurve.org/crypto.html, which is always brought up, but
never seems to solve the problems mentioned.
As I understand it, dnscurve protects transmissions, not objects.
That's not the way DNS operates today, what with N levels of cache. It
may or may not be better, but it's a much bigge
(2) Saying "type our name into $SERVICE", where $SERVICE is some
popular website that most people trust (like Facebook or whatever),
and has come up with a workable system for disambiguation.
I can only hope that those who believe in "disambiguation" of mailing
addresses, electronic or otherw
On Wed, Aug 5, 2009 at 7:30 PM, Mark Andrews wrote:
> Which requires that people type addresses in in the first
> place.
As I wrote, we're already part of the way towards people not having
to do even that.
> No they make finding a unique id easy by leveraging a
> ex
In message <59f980d60908051602y1fe364devfb5f590a8c795...@mail.gmail.com>, Ben S
cott writes:
> On Wed, Aug 5, 2009 at 6:37 PM, Chris Adams wrote:
> >>> ... we may not longer have the end user =93typing=94 a URL, the DNS or
> >>> something similar will still be in the background providing name to a
> (2) Saying "type our name into $SERVICE", where $SERVICE is some
> popular website that most people trust (like Facebook or whatever),
> and has come up with a workable system for disambiguation.
You might want to talk to AOL about that.
... JG
--
Joe Greco - sol.net Network Services - Milwauk
> I think it would be nice if we had some nicely designed, elegant,
> centralized protocol to do all this, but I suspect that won't happen.
s/centralized/distributed/
> them on their iPhone via some other damn thing. Yes, it'll be a mess.
Have you seen the iphone decoding bar code into urls ?
On Wed, Aug 5, 2009 at 7:06 PM, Jorge Amodio wrote:
> Talking about the subject with a friend during the past few days, most of
> the conversation ended being around the User Interface.
A popular idiom is "where the rubber meets the road". It comes from
cars, of course. The contact patch betwe
>> At some time in the future and when a new paradigm for the user interface is
>> conceived, we may not longer have the end user “typing” a URL, the DNS or
>> something similar will still be in the background providing name to address
>> mapping but there will be no more monetary value associated
On Wed, Aug 5, 2009 at 6:37 PM, Chris Adams wrote:
>>> ... we may not longer have the end user “typing” a URL, the DNS or
>>> something similar will still be in the background providing name to address
>>> mapping ...
>>
>> In the the vast majority of cases I have seen, people don't type
>> doma
On 8/5/09 2:49 PM, Christopher Morrow wrote:
and state-management seems like it won't be too much of a problem on
that dns server... wait, yes it will.
DNSSEC UDP will likely become problematic. This might be due to
reflected attacks, fragmentation related congestion, or packet loss.
When it
Once upon a time, Ben Scott said:
> In the the vast majority of cases I have seen, people don't type
> domain names, they search the web. When they do type a domain name,
> they usually type it into the Google search box.
Web != Internet. DNS is used for much more than web sites, and many of
On Aug 5, 2009, at 6:26 PM, Ben Scott wrote:
On Wed, Aug 5, 2009 at 12:49 PM, Jorge Amodio
wrote:
At some time in the future and when a new paradigm for the user
interface is
conceived, we may not longer have the end user “typing” a URL, the
DNS or
something similar will still be in the b
On Wed, Aug 5, 2009 at 12:49 PM, Jorge Amodio wrote:
> At some time in the future and when a new paradigm for the user interface is
> conceived, we may not longer have the end user “typing” a URL, the DNS or
> something similar will still be in the background providing name to address
> mapping bu
On Wed, 5 Aug 2009 15:07:30 -0400 (EDT)
"John R. Levine" wrote:
> >> 5 is 'edns ping', but it was effectively blocked because people
> >> thought DNSSEC would be easier to do, or demanded that EDNS PING
> >> (http://edns-ping.org) would offer everything that DNSSEC offered.
> >
> > I'm surpri
On Wed, Aug 5, 2009 at 5:24 PM, Douglas Otis wrote:
> On 8/5/09 11:31 AM, Roland Dobbins wrote:
>>
>> On Aug 6, 2009, at 1:12 AM, Douglas Otis wrote:
>>
>>> Having major providers support the SCTP option will mitigate disruptions
>>> caused by DNS DDoS attacks using less resources.
>>
>> Can you el
On 8/5/09 11:31 AM, Roland Dobbins wrote:
On Aug 6, 2009, at 1:12 AM, Douglas Otis wrote:
Having major providers support the SCTP option will mitigate disruptions caused
by DNS DDoS attacks using less resources.
Can you elaborate on this (or are you referring to removing the spoofing
vecto
> Read "Patterns in Network Architecture" by John Day.
"A Return to Fundamentals", great book.
"the Internet today is more like DOS, but what we need should be more like Unix"
Great thing he didn't say Windows :-)
Cheers
On 8/5/09 11:38 AM, Skywing wrote:
That is, of course, assuming that SCTP implementations someday clean up their act a bit.
I'm not so sure I'd suggest that they're really ready for "prime time" at this
point.
SCTP DNS would be intended for ISPs validating DNS where there would be
fewer iss
--- jmamo...@gmail.com wrote:
From: Jorge Amodio
Sooner or later, we or the new generation of ietfers and nanogers, will need to
start thinking about a new naming paradigm and design the services and protocols
associated with it.
The key question is, when we start?
3 works, but offers zero protection against 'kaminsky spoofing the
root' since you can't fold the case of "123456789.". And the root is
the goal.
Good point.
5) Download your own copy of the root zone every few days from
http://www.internic.net/domain/, check the signature if you can find the
5 is 'edns ping', but it was effectively blocked because people
thought DNSSEC would be easier to do, or demanded that EDNS PING
(http://edns-ping.org) would offer everything that DNSSEC offered.
I'm surprised you failed to mention http://dnscurve.org/crypto.html,
which is always
o: John Levine
Cc: nanog@nanog.org
Subject: Re: DNS hardening, was Re: Dan Kaminsky
On 8/5/09 9:48 AM, John Levine wrote:
> Other than DNSSEC, I'm aware of these relatively simple hacks to add
> entropy to DNS queries.
>
> 1) Random query ID
>
> 2) Random source port
>
On Aug 6, 2009, at 1:12 AM, Douglas Otis wrote:
Having major providers support the SCTP option will mitigate
disruptions caused by DNS DDoS attacks using less resources.
Can you elaborate on this (or are you referring to removing the
spoofing vector?)?
---
On Aug 5, 2009, at 1:30 PM, Jorge Amodio wrote:
It may sound too futuristic and inspired from science fiction, but
I never saw
Captain Piccard typing a URL on the Enterprise.
That's ok, I've never seen the Enterprise at the airport.
Go to Dulles Airport. She used to be on the runwa
On 8/5/09 9:48 AM, John Levine wrote:
Other than DNSSEC, I'm aware of these relatively simple hacks to add
entropy to DNS queries.
1) Random query ID
2) Random source port
3) Random case in queries, e.g. GooGLe.CoM
4) Ask twice (with different values for the first three hacks) and
compare the
bert hubert (bert.hubert) writes:
>
> 5 is 'edns ping', but it was effectively blocked because people
> thought DNSSEC would be easier to do, or demanded that EDNS PING
> (http://edns-ping.org) would offer everything that DNSSEC offered.
I'm surprised you failed to mention http://dnscurve
>> That's ok, I've never seen the Enterprise at the airport.
>
> I have, but not that Enterprise (I saw the space shuttle orbiter
> Enterprise on a 747 land here).
There is one docked at Pier 26 in New York City :-)
>> It may sound too futuristic and inspired from science fiction, but I never
>> saw
>> Captain Piccard typing a URL on the Enterprise.
>
> That's ok, I've never seen the Enterprise at the airport.
Don't confuse sight with vision.
>> Sooner or later, we or the new generation of ietfers an
Once upon a time, Phil Regnauld said:
> Jorge Amodio (jmamodio) writes:
> > It may sound too futuristic and inspired from science fiction, but I never
> > saw
> > Captain Piccard typing a URL on the Enterprise.
>
> That's ok, I've never seen the Enterprise at the airport.
I have, but not
Jorge Amodio (jmamodio) writes:
>
> It may sound too futuristic and inspired from science fiction, but I never saw
> Captain Piccard typing a URL on the Enterprise.
That's ok, I've never seen the Enterprise at the airport.
> Sooner or later, we or the new generation of ietfers and nanoge
On Wed, Aug 5, 2009 at 6:48 PM, John Levine wrote:
> 3) Random case in queries, e.g. GooGLe.CoM
> 4) Ask twice (with different values for the first three hacks) and
> compare the answers
>
> I presume everyone is doing the first two. Any experience with the
> other two to report?
3 works, but off
> My interest was in replacing the protocol. I've grown fond of the
> name space, for all of its warts.
As we evolved from circuit switching to packet switching, which many at the
time said it would never work, and from the HOSTS.TXT to DNS, sooner or later
the “naming scheme” for resources on th
Other than DNSSEC, I'm aware of these relatively simple hacks to add
entropy to DNS queries.
1) Random query ID
2) Random source port
3) Random case in queries, e.g. GooGLe.CoM
4) Ask twice (with different values for the first three hacks) and
compare the answers
I presume everyone is doing th
In a message written on Wed, Aug 05, 2009 at 02:32:27PM +, Florian Weimer
wrote:
> The transport protocol is a separate issue. It is feasible to change
> it, but the IETF has a special working group which is currently tasked
> to prevent any such changes.
My interest was in replacing the pro
On Aug 5, 2009, at 10:20 PM, Erik Soosalu wrote:
Multiple systems end up with problems.
Yes, and again, I'm not advocating this approach. I just think it's
most likely where we're going to end up, long-term.
---
Roland D
On Aug 5, 2009, at 10:11 PM, Mark Andrews wrote:
For all it's short comings the DNS and the single namespace it
brings is much better than
having a multitude of namespaces.
I agree with you, but I don't think this approach is going to persist
as the standard model.
Increasingly, trans
[mailto:rdobb...@arbor.net]
Sent: Wednesday, August 05, 2009 10:44 AM
To: NANOG list
Subject: DNS alternatives (was Re: Dan Kaminsky)
On Aug 5, 2009, at 9:32 PM, Florian Weimer wrote:
> We might have an alternative one day, but it's going to happen by
> accident, through generaliz
In message <825c8ac7-c01e-4934-92fd-e7b9e8091...@arbor.net>, Roland Dobbins wri
tes:
>
> On Aug 5, 2009, at 9:32 PM, Florian Weimer wrote:
>
> > We might have an alternative one day, but it's going to happen by
> > accident, through generalization of an internal naming service
> > employed b
On Aug 5, 2009, at 9:32 PM, Florian Weimer wrote:
We might have an alternative one day, but it's going to happen by
accident, through generalization of an internal naming service
employed by a widely-used application.
Or even more likely, IMHO, that more and more applications will have
t
On 05/08/2009 15:18, Leo Bicknell wrote:
> I don't understand why replacing DNS is "not feasible".
I'd be happy to think about replacing the DNS as soon as we've finished
off migrating to an ipv6-only internet in a year or two.
Shall we set up a committee to try to make it happen faster?
Nick
* Leo Bicknell:
> In a message written on Tue, Aug 04, 2009 at 11:32:46AM -0700, Kevin Oberman
> wrote:
>> There is NO fix. There never will be as the problem is architectural
>> to the most fundamental operation of DNS. Other than replacing DNS (not
>> feasible), the only way to prevent this for
In a message written on Tue, Aug 04, 2009 at 11:32:46AM -0700, Kevin Oberman
wrote:
> There is NO fix. There never will be as the problem is architectural
> to the most fundamental operation of DNS. Other than replacing DNS (not
> feasible), the only way to prevent this form of attack is DNSSEC. T
On Tue, Aug 4, 2009 at 9:25 PM, Paul Vixie wrote:
> i didn't pay any special heed to it since there was no way to get enough
> bites at the apple due to negative caching. when i saw djb's announcement
> (i think in 1999 or 2000, so, seven years after schuba's paper came out) i
> said, geez, that's
On 3-Aug-09, at 9:43 PM, andrew.wallace wrote:
Hi,
Read my post one more time and think though: Only "zf0" are legally
in the shit.
The guy "Dragos Ruiu" has absolutely no case against me.
Copy & paste doesn't count as defamation, speak to Wired's legal team
if you have an issue.
Cheers,
Curtis Maurand writes:
>> What does this have to do with Nanog, the guy found a critical
>> security bug on DNS last year.
>
> He didn't find it. He only publicized it. the guy who wrote djbdns fount
> it years ago.
first blood on both the DNS TXID attack, and on what we now call the
Kashpuref
There is NO fix. There never will be as the problem is architectural
to the most fundamental operation of DNS. Other than replacing DNS
(not
feasible), the only way to prevent this form of attack is DNSSEC. The
"fix" only makes it much harder to exploit.
Randomizing source ports and QIDs simp
> Date: Tue, 04 Aug 2009 13:32:42 -0400
> From: Curtis Maurand
>
> andrew.wallace wrote:
> > On Thu, Jul 30, 2009 at 11:48 PM, Dragos Ruiu wrote:
> >
> >> at the risk of adding to the metadiscussion. what does any of this have to
> >> do with nanog?
> >> (sorry I'm kinda irritable about charac
On Tue, 4 Aug 2009, valdis.kletni...@vt.edu wrote:
Yes, but a wise man without a PR agent doesn't do the *rest* of the
community much good. A Morris or Bernstein may *see* the problem a
decade before, but it may take a Mitnick or Kaminsky to make the *rest*
of us able to see it...
Same thin
On Tue, 04 Aug 2009 13:32:42 EDT, Curtis Maurand said:
> > What does this have to do with Nanog, the guy found a critical
> > security bug on DNS last year.
> >
> He didn't find it. He only publicized it. the guy who wrote djbdns
> fount it years ago. Powerdns was patched for the flaw a yea
andrew.wallace wrote:
On Thu, Jul 30, 2009 at 11:48 PM, Dragos Ruiu wrote:
at the risk of adding to the metadiscussion. what does any of this have to
do with nanog?
(sorry I'm kinda irritable about character slander being spammed out
unnecessarily to unrelated public lists lately ;-P )
Hi,
Read my post one more time and think though: Only "zf0" are legally in the shit.
The guy "Dragos Ruiu" has absolutely no case against me.
Copy & paste doesn't count as defamation, speak to Wired's legal team
if you have an issue.
Cheers,
Andrew
On Tue, Aug 4, 2009 at 2:02 AM, Richard A St
Read my post one more time... The standards you described are what I
described. No video, no audio = no speech = no slander. The article
was written, hence libel.
On Aug 3, 2009, at 6:02 PM, Richard A Steenbergen wrote:
On Sat, Aug 01, 2009 at 01:11:17PM -0700, Cord MacLeod wrote:
I do
On Sat, Aug 01, 2009 at 01:11:17PM -0700, Cord MacLeod wrote:
> I don't see a video attached or an audio recording. Thus no slander.
>
> Libel on the other hand is a different matter.
You have those backwards. Slander is transitory (i.e. spoken)
defamation, libel is written/recorded/etc non-tran
I don't see a video attached or an audio recording. Thus no slander.
Libel on the other hand is a different matter.
On Aug 1, 2009, at 8:10 AM, andrew.wallace wrote:
On Thu, Jul 30, 2009 at 11:48 PM, Dragos Ruiu wrote:
at the risk of adding to the metadiscussion. what does any of this
have
On Thu, Jul 30, 2009 at 11:48 PM, Dragos Ruiu wrote:
> at the risk of adding to the metadiscussion. what does any of this have to
> do with nanog?
> (sorry I'm kinda irritable about character slander being spammed out
> unnecessarily to unrelated public lists lately ;-P )
>
What does this have to
On Thu, Jul 30, 2009 at 03:48:18PM -0700, Dragos Ruiu wrote:
>
> On 29-Jul-09, at 9:23 PM, Randy Bush wrote:
>
> >Ettore Bugatti, maker of the finest cars of his day, was once asked
> >why
> >his cars had less than perfect brakes. He replied something like,
> >"Any
> >fool can make a car sto
On 29-Jul-09, at 9:23 PM, Randy Bush wrote:
LAS VEGAS — Two noted security professionals were targeted this
week
by hackers who broke into their web pages, stole personal data and
posted it online on the eve of the Black Hat security conference.
boring.
Two noted security professionals,
--- On Wed, 7/29/09, Scott Weeks wrote:
> From: Scott Weeks
> Subject: Re: Fwd: Dan Kaminsky
> To: "andrew.wallace"
> Date: Wednesday, July 29, 2009, 10:10 PM
>
>
> --- andrew.wall...@rocketmail.com
> wrote:
>
> http://www.leetupload.com/zf05.txt
> --
>
>
88 matches
Mail list logo
