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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Michael StJohns writes:
> 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 decisio
> n about what it wants to send to a stub based on the intermediate's understand
> ing 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 s
> erver of the validating resolver).

	If any part fails to pass validation the client gets SERVFAIL
	after repeated attempts to get the answer.

	If it passes validation and the client doesn't ask for AD
	you just get the ordinary answer.

	If it passes validation and the client asks for AD (by
	setting DO or AD) you get the answer with AD set iff all
	of the RRsets in the answers and authority sections are
	proved secure otherwise you get the answer without AD set.

	Mark

> Mike
> 
> ps - anyone want to take a whack at documenting how various applications shoul
> d handle various DNSSEC outcomes?  The ones I can think of off the top of my h
> ead 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 exp
> osing 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 verif
> y.
> >>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 hack
> er 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 v
> erified, it will also know that it got other records for which there is no anc
> illary 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 applicatio
> ns.  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 a
> re.
> >
> >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/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]

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