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

[Michael StJohns <[e-mail]>]

If "intermediate validation to protect legacy stub resolvers" were deprecated, I'd agree with you.  (can we please huh huh can we deprecate it????) 

Since we're still touting the utility of having an intermediate make a decision about what it wants to send to a stub based on the intermediate's understanding of security, we need to pick a consistent understanding of that security.  (In other words, the application we're concerned with here is the stub side server of the validating resolver).

Mike

ps - anyone want to take a whack at documenting how various applications should handle various DNSSEC outcomes?  The ones I can think of off the top of my head that should be done are: SMTP (both submitter to MTA and MTA to MTA), HTTP (what the browser does *before* the user gets involved - pretty sure just exposing the DNSSEC resolution state isn't the best answer), SSH,  peer-to-peer.

At 06:21 AM 9/24/2008, Edward Lewis wrote:
>At 21:24 -0400 9/22/08, Michael StJohns wrote:
>
>>Original query is:  "www.somewhere.example.com A" and we have a trust anchor for somewhere.example.com
>>At somewhere.example.com is a DNAME into unsecure.com which is not signed or for which we have no trust anchor.
>>At www.unsecure.com is a CNAME pointing at www.otherexample.com
>>We have a trust anchor for otherexample.com and the zone contents will verify.
>>At www.otherexample.com is a A record - the answer to our original query.
>>
>>It turns out the original data at www.unsecure.com was an A record... a hacker got in and changed it.
>>
>>Does the result parse out as verified?  Should it?
>
>This isn't a problem for the DNS, it's a problem for the application.
>
>DNSSEC will allow the querier to know that it got some records and they are verified, it will also know that it got other records for which there is no ancillary protection information.  DNSSEC will not permit "protected" records to be spoofed (within the bounds of what it can do).
>
>So far as whether the "final answer" is right, that's an issue for applications.  The application would have to make the judgement whether it would accept the "chain" of DNAMEs and CNAMEs - or judge what the semantics of the proofs are.
>
>Perhaps a discussion of this belongs in the Security Considerations of DNSSEC bis.
>-- 
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                                [phone]
>NeuStar
>
>Never confuse activity with progress.  Activity pays more.
>
>--
>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/>



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