Re: How do we get the whole world to upgrade to DNSSEC capable resolvers?

[Brian Dickson <[e-mail]>]

bert hubert wrote:
> On Wed, Jul 23, 2008 at 02:14:10PM -0700, David Conrad wrote:
>   
>> You are constraining the problem so the solution you prefer fits.  The  
>>     
>
> No, it goes beyond that. I've constrained the problem to protecting DNS
> against people that do not have the ability to intercept and modify your
> packets.
>
> This is not an arbitrary restriction. People that CAN modify your
> packets in transit are a wholly different problem - they don't even need to
> bother with DNS to mess with your traffic. They can do so directly. Not even
> DNSSEC will stop them!
>
>   

I beg to differ.

The presumption you are making is, that (a) the people modifying the DNS 
are the same people hijacking
your traffic, and (b) that no benefit can be brought by use of DNSSEC in 
this scenario.

Allow me to provide a concrete example, typical of an IETF attendee who 
knows what they are doing.

Joe is attending an IETF. He stays in a hotel. He uses his laptop to 
access the internet via the hotel's network.

The hotel outsources their network stuff to a shady operator, who likes 
to hijack DNS packets so as to replace
ads with other ads.

All DNS traffic gets directed to a caching resolver that has been hacked 
for just such a purpose.
That hacked resolver is vulnerable to the Kaminsky attack, and is poisoned.

Joe has his own local recursive resolver running on his laptop, and 
wants to access his bank's web site.
He types in http://mybank.tld which should redirect him to 
https://special-thing.mybank.tld.

His resolver does its thing, but before it gets very far, the DNS 
queries it makes get intercepted, and bad
answers from the hacked box get sent back, instead sending him to 
https://phishing-site.tld.

DNSSEC makes this impossible.

Note that the ability to access packets in flight is irrelevant, so long 
as the proper DNS answers are served,
and redirects from non-https to https get done properly. Once the https 
is reached, TLS/SSL protects things,
but the key is reaching the right sight to start with.

Without the ability to handle non-https initiation URLs safely via DNS, 
it's all a house of cards.

Saying that not using https for everything, is blaming the victim.

So, in short, DNSSEC is the only answer that gets around this very real, 
very well known problem.

The idea of using other methods of hardening DNS resolvers is flawed, 
when not everyone operating
a resolver is necessarily strongly incented to harden their resolver 
(e.g. the hotel outsourcing folks).

> And this defines the natural bounding box for how secure DNS MUST be, and
> with it a limit on the burden of securing it.
>   

I disagree that your choice is natural, and I disagree that it is 
sufficient.

Brian

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>