Subject: Re: [dnsext] Reminder: two WGLC closing in one week

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Sep 2008 11:36:09 +1000

In message <[email-masked]>, Michael StJohns writes:
> 
> I started to write a longish response, but got to a point where I think I have 
> a question that sort of explains where I'm coming from.  For Mark's message ask
> ing how this differs from CNAME - there are basically two types of CNAME - thos
> e with targets under the original trust anchor and those that aren't. The forme
> r have no real cascade implications as long as the final target and all of the 
> intermediates are under the same trust anchor.
> 
> The latter type are most like DNAME, I haven't seen any security analysis of a 
> CNAME cascade.  I may have missed it over the years - if so I apologize for my 
> ignorance.
> 
> In the most complex lookup case, we've got cascades of CNAME and DNAME lookups 
> - each being treated in isolation from each other for security purposes.  Is th
> is a correct treatment?  Or just the treatment that's possible given the curren
> t definitions?
> 
> For example, we start a query in a secure zone - it validates; but DNAMEs into 
> an unsecure zone; and bounces (CNAMEs) back into a secure zone which also valid
> ates.  Is the "result" secure, unsecure or some other state?  

	AD is not set by the validating recursive server as not all
	components of the answer and authority sections validated
	as secure.
 
> Original query is:  "www.somewhere.example.com A" and we have a trust anchor fo
> r somewhere.example.com
> At somewhere.example.com is a DNAME into unsecure.com which is not signed or fo
> r 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?

	Has no impact on the setting of AD.  Unsecure is unsecure
	regardless of whether the answer is what should be there
	or not.
 
> Given that once a validator wanders in to an insecure zone, it can be steered w
> here ever, should we ever mark that data as "trusted validated"?  Sure the last
>  question validated, but the fact that it did is probably worthless for determi
> ning the security of the query response.

	Correct.  The entire chain needs to be secure for AD to be set.
 
> 
> At 08:16 PM 9/22/2008, Mark Andrews wrote:
> 
> >In message <[email-masked]>, Michael StJohns writes:
> >> Hi Andrew -
> >> 
> >> At Scott's request I took a look at the dname document.  Keep in mind that I
> 'm 
> >> looking at it pretty much for the first time.  Unfortunately, I don't think 
> its
> >>  ready for prime-time.  Most of the document is fine - but the section on DN
> SSE
> >> C is woefully lacking.
> >> 
> >> DNSSEC unfortunately makes things more difficult.  Having DNAMEs plus DNSSEC
>  st
> >> retches the complications almost to the breaking.
> >
> >        How?
> > 
> >> The section needs more than a 1 page description of why DNSSEC servers need 
> to 
> >> understand DNAME, it needs a discussion of the various combinations of modes
>  in
> >> which a resolver can find itself when following a DNAME chain.
> >
> >        Why?  DNAME is a method to synthesis a CNAME.  Once you have the
> >        CNAME you give it the *same* trust level that you gave the DNAME
> >        and proceed as if there was just a CNAME there.
> > 
> >> For example - what happens if the DNAME is signed, but the referenced target
>  is
> >> n't?
> >
> >        What happens if a CNAME validates and the name it points to doesn't?
> >
> >> What happens if both are signed, but the resolver doesn't have a trust an
> >> chor for the target but has one for the DNAME?  For the DNAME but not the ta
> rget
> >
> >        What happens if a CNAME is signed an it's target is signed but you
> >        don't have a trust anchor for the target?
> >
> >> ?  What happens if the DNAME is directly reachable (e.g. querier is a valida
> tin
> >> g recursive resolver) but the target is available only through a forwarder?
> >
> >        What happens is the CNAME is directly reachable but the target is
> >        available only through a forwarder?
> >
> >> What happens if the DNAME and the target are signed with different algorithm
> >> and the querier only understands one of they.
> >
> >        What happens if the CNAME and the target are signed with different
> >        algorithm and the  querier only understands one of they?
> >
> >> I can see about a number of  different ways to have different resolvers beha
> ve 
> >> given different combinations.  I think they need to be called out and a spec
> ifi
> >> c behavior proposed for each prior to sending this forward.
> >
> >        Why.  The answers to DNAME are really no different to how you handle
> >        the CNAME.
> >
> >        The only thing really different about DNAME is to handle YXDOMAIN.
> >
> >        Mark
> > 
> >> One proposal, once the "must be signed bit" is set (e.g. DNAME or target sub
> ord
> >> inate to a trust anchor without a delegation to unsecure), then ALL data mus
> t b
> >> e signed to be considered valid.  (Not sure this is the right way of doing t
> hin
> >> gs, but its a conversation starter).
> >> 
> >> Sorry - Mike
> >-- 
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

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

---

From: Michael StJohns <[email-masked]>
Date: Mon, 22 Sep 2008 22:52:10 -0400

OK - so if the last chain validates, but the intermediate chain was unsecure, then you return the answer, but don't set the AD bit.  If the last chain doesn't validate, you return what?  The data without the AD bit, or  RCODE 2/SERVFAIL?  (I.e.is it really possible to have data that's both bogus and unsecure?) Is there any reason to do validation for the third chain in my example once you've wandered over into unsecure land?  

Where - exactly - in the documentation of either CNAME or DNAME (or DNSSEC for that matter) is your last conclusion stated as a specific protocol element?  I just back and review 4035 sections 3.1.6, 3.2.3 and 5 and they don't seem to say this.  The definition for "secure" in 4.3 only says to trace from the answer to a trust anchor.  The definition for insecure *could* be read to say what you said, but then it would be in conflict with the definition for "secure".

I don't disagree with you about the output, but I do disagree that the result is obvious enough not to require specific documentation.