On Mon, Aug 18, 2008 at 03:47:46PM -0700, David Conrad wrote:
> In today's Internet, most network engineers (at least at real companies)
> don't go turning on new, weird technologies for fun.
This is true.
> If some technology is going to be deployed, there is generally a
> business reason fo
On Tue, Aug 19, 2008 at 08:55:31AM -0400, Andrew Sullivan wrote:
> Now, maybe that doesn't matter for many of these cases. It is
> entirely possible that DNSSEC deployment for most zones is just not
> worth it. If that's true, however, why are we so worried about poison
> attacks?
Because quite
David Conrad wrote:
> NAT does not need to be modified. As I type this, I am behind a
> commercial (relatively low end -- an Apple Airport Extreme basestation)
> NAT with firewalling enabled. It works just fine.
So what? NAT at airport must be, unlike NATs in enterprises,
consumer friendly.
On Aug 19, 2008, at 6:40 AM, Masataka Ohta wrote:
So what? NAT at airport must be, unlike NATs in enterprises,
consumer friendly. Unlike highe end NAT, low end NAT won't
bother to interfere DNS.
Right. Because low-end consumer gear is always so much better
implemented than enterprise gear.
David Conrad wrote:
which you could have argue against 10 years ago but not now.
It's such a shame that computer processing technology for doing stuff
like cryptography hasn't advanced in 10 years.
Unfortunately, the Internet has grown in 10 years, too.
Do you want to fund my costs of su
Another 10 year delay would benefit all our respective businesses ;-) But to
move forward you sometimes have to take chances.
-Rick
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Ulevitch
Sent: Tuesday, August 19, 2008 9:09 AM
To: David Conrad
Cc:
On Tue, 19 Aug 2008, Andrew Sullivan wrote:
Sure, large organizations with large, mostly competent, and very
conservative IT departments (think "banks") will probably not have
this problem and will probably deploy successfully. None of that will
matter, however, if everyone else starts adopting
On Tue, Aug 19, 2008 at 12:07:04PM -0400, Paul Wouters wrote:
> Because this is only true for the authorative part of DNSSEC. Since
> Dan showed you can cache poison any non-DNSSEC resolver for ANY domain,
> not just the domains you are not protecting, you basically have no choice
> but to mitigate
On Aug 19, 2008, at 10:00 AM, bert hubert wrote:
In fact, I'm so far not having luck getting around even my 3-year old
primitive anti-spoofing behaviour.
Have you tried dsniff anywhere on the path the DNS packets take?
Regards,
-drc
___
DNSOP mailin
David,
On Aug 19, 2008, at 9:09 AM, David Ulevitch wrote:
which you could have argue against 10 years ago but not now.
It's such a shame that computer processing technology for doing
stuff like cryptography hasn't advanced in 10 years.
Unfortunately, the Internet has grown in 10 years, too.
On Tue, 19 Aug 2008, bert hubert wrote:
Is there some sort of shield preventing people from reading or even arguing
with
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01213.html
?
All those things can be done today, unilaterally, and they start working
from the moment you enab
On Aug 19, 2008, at 9:09 AM, David Ulevitch wrote:
I've yet to be shown how DNSSEC is any of those things. D-H key
exchanges, DTLS, DNS PING, all sound far more appealing.
A simple solution that doesn't work always sounds better than a
complex solution that does work, particularly if you anal
On Tue, 19 Aug 2008, bert hubert wrote:
In fact, I'm so far not having luck getting around even my 3-year old
primitive anti-spoofing behaviour.
Funny, that's not what Dan's talk said. PowerDNS specifically was trivial to
spoof based on bogus query types, since PowerDNS dropped those packets a
David Conrad wrote:
Do you want to fund my costs of supporting (and encouraging my clients
to use) DNSSEC?
I don't use your service. If your customers feel there is value in what
DNSSEC can provide, they'll presumably pay you for DNSSEC functionality
and if you don't have it, they'll find s
Andrew,
On Aug 19, 2008, at 5:55 AM, Andrew Sullivan wrote:
If some technology is going to be deployed, there is generally a
business reason for that to happen.
This is also true, but in my experience one of those business reasons
is, depressingly often, "This is the Current Thinking I read in
Ted Lemon wrote:
On Aug 19, 2008, at 9:09 AM, David Ulevitch wrote:
I've yet to be shown how DNSSEC is any of those things. D-H key
exchanges, DTLS, DNS PING, all sound far more appealing.
The answer to that question has to take into account what benefit
accrues to you from preventing DNSSEC
David,
On Aug 19, 2008, at 10:27 AM, David Ulevitch wrote:
Do you want to fund my costs of supporting (and encouraging my
clients to use) DNSSEC?
I don't use your service. If your customers feel there is value in
what DNSSEC can provide, they'll presumably pay you for DNSSEC
functionality
On Tue, 19 Aug 2008, David Conrad wrote:
On Aug 19, 2008, at 6:40 AM, Masataka Ohta wrote:
So what? NAT at airport must be, unlike NATs in enterprises,
consumer friendly. Unlike highe end NAT, low end NAT won't
bother to interfere DNS.
Right. Because low-end consumer gear is always so much
On Tue, 19 Aug 2008, David Ulevitch wrote:
Nonetheless, I'll share some data. I've yet to have a single person, who was
not a DNSSEC implementor or fanboy, request DNSSEC support at OpenDNS.
Well duh. For once, anyone who is asking you gets qualified as "fan boy", so
your
statement is self-fu
On Tue, 19 Aug 2008, David Ulevitch wrote:
Sort of. It means I have to start another company that will charge slightly
less egregious fees than the rest of you plan on doing to do DNSSEC
management for companies the same way Thawte and Verisign did for SSL certs.
Except now, there are no bro
On Tue, Aug 19, 2008 at 01:13:44PM -0400, Paul Wouters wrote:
> On Tue, 19 Aug 2008, bert hubert wrote:
>
> >In fact, I'm so far not having luck getting around even my 3-year old
> >primitive anti-spoofing behaviour.
>
> Funny, that's not what Dan's talk said. PowerDNS specifically was trivial to
On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote:
> it in their products or services. Peter Koch did provide an interesting
> data point that warrants further investigation (20-35% of queries having DO
> bit on seems a bit high to me) and someone else responded privately that
I th
On Tue, Aug 19, 2008 at 10:09:16AM -0700, David Conrad wrote:
> On Aug 19, 2008, at 10:00 AM, bert hubert wrote:
> >In fact, I'm so far not having luck getting around even my 3-year old
> >primitive anti-spoofing behaviour.
>
> Have you tried dsniff anywhere on the path the DNS packets take?
Not
On Aug 19, 2008, at 12:23 PM, bert hubert wrote:
Again - this is about TODAY. DNSSEC might be the end all solution
but even
if it is, it is not deployed widely today and it won't be 12 months
from
now.
Nobody's disputing that point. Is this why we are arguing? The
reason I'm pushing D
> > it in their products or services. Peter Koch did provide an interesting
> > data point that warrants further investigation (20-35% of queries having DO
> > bit on seems a bit high to me) and someone else responded privately that
>
> I think Peter's data point sure warrants further investig
On Aug 19, 2008, at 2:09 PM, [EMAIL PROTECTED] wrote:
Peter Koch did provide an interesting
data point that warrants further investigation (20-35% of queries
having DO
bit on seems a bit high to me)
From my own limited investigations (less than 10 servers, but millions
of DNS queries thus h
On Mon, 18 Aug 2008, bert hubert wrote:
>
> What's the rush with deprecating DNS/TCP btw? It languished in the shade for
> 25 years..
TCP doesn't work with Anycast, as was stated in RFC1546. And Root
server operators are supposed to offer TCP to everyone, not just those
that use the stateless UD
The claims that verifying DNSSEC caches can't be poisoned isn't true
after all.
On Tue, 19 Aug 2008, Masataka Ohta wrote:
> A property of Kaminsky's attack that it is effective against a single
> target is useful, here.
I don't know if anyone noticed, but in fact, according to RFC4035 the
deleg
On Aug 19, 2008, at 8:15 PM, Dean Anderson wrote:
A verifying
DNSSEC cache can be poised with bad glue records using the poisoning
attack, with only a slight change to the Kaminsky software.
Do you mean that it can be convinced that an answer is valid when it
is not?
___
29 matches
Mail list logo
