Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME

[Nicholas Weaver <[e-mail]>]

On Oct 14, 2008, at 7:26 AM, Edward Lewis wrote:

> At 21:35 +0100 10/13/08, Ben Laurie wrote:
>
>> Broadly I agree, except I think you can also choose BOGUS ==  
>> UNSECURE ==
>> UNKNOWN.
>
> Such a strategy is akin to (today) only using IPv6. ;)  That is,  
> most of the network is not doing DNSSEC and not doing IPv6.
>
> Equating SEURE, UNSECURE, and UNKNOWN is what I think is more to the  
> spirit of DNSSEC and incremental deployment.  It's a recognition  
> that what can be secure is but you still have access to the legacy  
> network.
>
> Equating BOGUS, UNSECURE, and UNKNOWN is a paranoid strategy, only  
> trusting what you can see and touch.
>
> In some circles I can understand the paranoia.  But most of the  
> economy needs open access and a willingness to accept risk.

Then why not the following:

DNSSEC has two uses:  Secure name lookup, and as Another CA  
Infrastructure Run By Verisign Combined With A Hierarchical  
Distributed Integrity Data Store for small datums.  For "Another CA  
Infrastructure", the end application needs full control and full  
information, and a much richer API then gethostbyname().


But for secure name lookup, DNSSEC's additional protection is against  
in-path adversaries.  The adversary on the wire is not a real concern  
to my mind for DNS (its a concern for the end application).

But as witnessed by David Dagon's work, ISP's which wildcard failures,  
and even legitimate sites like OpenDNS man-in-the-middling some names  
( dig www.google.com @208.67.222.222 ), the recursive resolver IS an  
in-path adversary and a serious concern.


Thus why not the following default policy:  If the host's stub  
resolver is actually caring about DNSSEC ("secure name lookup"),  
operate in the following mode:

a)  If the stub resolver can fully validate a complete signature chain  
for the record returned from the recursive resolver, accept it, cache  
it, return it for gethostbyname() and have a nice day.

b)  If, FOR ANY REASON, the stub resolver can not fully validate the  
complete signature chain (expired signature, bad signature, recursive  
resolver lying, recursive resolver stating "What's DNSSEC d00d?"), it  
conducts a complete recursive fetch of its own to get the value to be  
returned to the querying application, and does not cache any record  
that doesn't have a valid signature.


This way, all failures of DNSSEC (or failure to USE DNSSEC) will still  
resolve, and, as importantly, they will resolve over what will be  
effectively the same path for in-path adversaries as the application  
will face.

I will argue that this is the correct behavior, because any  
application which would trust the name is probably vulnerable to the  
MitM anyway, so you haven't increased the vulnerability to the end  
application generating the query, but did not act as a denial-of- 
service attack because of a signature failure.


--
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/>