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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Michael StJohns writes:
> At 11:09 PM 9/22/2008, Mark Andrews wrote:
> 
> >In message <[e-mail]>, Michael StJohns writes:
> >> OK - so if the last chain validates, but the intermediate chain was unsecure
> , t
> >> hen you return the answer, but don't set the AD bit.  If the last chain does
> n't
> >>  validate, you return what?  The data without the AD bit, or  RCODE 2/SERVFA
> IL?
> >
> >        SERVFAIL.  If they ask with cd=1 then they get the full answer.
> >
> >>   (I.e.is it really possible to have data that's both bogus and unsecure?)
> >
> >        A particulare RRset is falls into exactly one of secure, insecure or
> >        bogus post validation.
> 
> Right, but the answer is a mixture of three RRSets - one secure, one unknown an
> d one bogus... which I guess makes the whole thing bogus and results in the ret
> urn of RCODE 2.
> 
> 
> >> Is t
> >> here any reason to do validation for the third chain in my example once you'
> ve 
> >> wandered over into unsecure land?  
> >
> >        Yes as you may be asked the later question.
> 
> Fair enough.
> 
> 
> >> Where - exactly - in the documentation of either CNAME or DNAME (or DNSSEC f
> or 
> >> 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
>  sa
> >> y this.  The definition for "secure" in 4.3 only says to trace from the answ
> er 
> >> 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".
> >
> >   A security-aware name server MUST NOT set the AD bit in a response
> >   unless the name server considers all RRsets in the Answer and
> >   Authority sections of the response to be authentic.  
> 
> OK. I can go along with this reading - but I think I'm still not quite done.
> 
> 
> So the last question is what goes on when you have the same three queries - exc
> ept the last one now validates, and the DO bit wasn't set from the stub resolve
> r? (e.g, I won't understand the lack of AD bit)

	You return the answer.
 
> The simple answer would be to return the three RRSets - but is that the right a
> pproach or only one of several correct approaches?  
> 
> I could argue the paranoids point, that once the answer becomes secure, unless 
> it becomes securely unsecure (by proving there's no DS at a delegation point), 
> then the final answer must either be secure or bogus.  In other words, if I get
>  a referral via a CNAME or DNAME into unsecure space, then the final answer sho
> uld be "bogus".

	No.  Everything that is not at or below a TA is deemed to
	be insecure.

> The above is different than the secure delegation to an unsecure zone:  The sig
> ned delegation to an unsigned zone is controllable by the delegator.  The signe
> d CNAME or DNAME referral to an zone carries no information about whether the r
> eferrer/signer believes the target zone/name should be signed.  
>
> I'm trying to reconcile this with the general policies on how data is returned 
> from a validating recursive resolver to a non-DNSSEC aware stub resolver.  The 
> VRR returns an RCODE 2 for any data below a trust anchor it can't validate (bog
> us), and returns the data which has no superior trust anchor (unknown),

	No, it is NOT unkown.  It is insecure.  You are attempting to introduce
	a state which does not exist.

	secure -> passes validation
	insecure -> no TA or there is a insecure delegation from a secure zone.
	bogus -> fails validation

> returns
> the data it was able to validate (secure), and returns the data which was belo
> w an unsecure delegation point (unsecure). 
> 
> I'm not sure I can argue that a DNAME or CNAME into an unknown/unsecure zone fr
> om a secure zone is equivalent to an unsecure delegation from that secure zone 
> to a subsidiary, because the target of the DNAME/CNAME can change the DNSSEC st
> atus at any time after the CNAME/DNAME is published.  Unfortunately, I can't se
> e any way of encoding the DNAME/CNAME signers expectation of security for the t
> arget zone in the current definitions.

	Each QNAME when following a CNAME chain is independently
	validated.  When you return the final answer you look at
	all the components to determine whether the final answer
	is secure (AD could be set if requested) or not.
 
> So if I follow the principal of "if it started out secure and I can't prove it 
> was meant to be unsecure then it should be bogus if I can't validate it" which 
> we follow for on-tree delegations, shouldn't I follow it for off-tree delegatio
> ns?

	Except you can validate that it is insecure.

	Mark

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