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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, 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 <[e-mail]>, 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: [phone]                 INTERNET: [e-mail]
> 
> 
-- 
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/>