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

[Nicholas Weaver <[e-mail]>]

On Oct 13, 2008, at 4:38 AM, Michael StJohns wrote:
>
> I don't think its this simple... really.
>
> Basic DNS has the 3 answers in your first group - although I'd  
> categorize the last one as "I can't make any determination about  
> whether or not the answer exists for any of a number of reasons" -  
> what Marc describes as "indeterminate".
>
> DNSSEC  add 4 (actually maybe even 5) security states that are  
> somewhat orthogonal to the DNS states:

Possibly:

6:  Leap-of-faith.  Its "unknown" but its the same trust anchor that I  
have previously seen for this domain at some long time previously.

7:  Leap-of-faith failure.  Its "unknown" and different from the first  
time I've seen the trust anchor for this domain.

> I'm not trying to be difficult here - but considering each of these  
> intersections and figuring out what to do for each application seems  
> to be a reasonable approach.

The problem with relying on end-application validation of the states  
is that there is really only three possible answers, and none of them  
really rely on the detailed answers that the resolver gives:

1: The network is not trusted by the application, thus you need to  
verify end-to-end the other side.

Once the application makes this decision, DNS for purposes of name- 
 >address mapping is irrelevant for security purposes, although DNSSEC  
does matter if you care about a name->public_key mapping because you  
are using DNSSEC as a CA instead of any other CA or leap-of-faith key- 
exchange mechanisms.


2: The Network is trusted by the application.

Once the application makes this decision, it might as well accept  
everything as long as the resolver implements the defenses against OUT- 
of-path attacks, which is orthoginal to what you do in several of the  
key-failure corner-cases.


3:  The Network is trusted by the application, but the recursive  
resolver belonging to the ?ISP? isn't.  (The Rogue resolution- 
authority problem)

IF the application makes this decision, it should simply use its own  
non-DNSSEC recursive resolver to make queries and bypass the external  
recursive resolver altogether, because such a recursive resolver can  
always just say "uhh, no DNSSEC here".


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