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

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

In message <[email-masked]>, 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 doesn't
>  validate, you return what?  The data without the AD bit, or  RCODE 2/SERVFAIL?

	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.

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

> 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 sa
> y 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".

   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.  A security-aware
   name server's local policy MAY consider data from an authoritative
   zone to be authentic without further validation.  However, the name
   server MUST NOT do so unless the name server obtained the
   authoritative zone via secure means (such as a secure zone transfer
   mechanism) and MUST NOT do so unless this behavior has been
   configured explicitly.

	Mark
-- 
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: Tue, 23 Sep 2008 00:37:21 -0400

>        A particulare RRset is falls into exactly one of secure, insecure or

Right, but the answer is a mixture of three RRSets - one secure, one unknown and one bogus... which I guess makes the whole thing bogus and results in the return of RCODE 2.

>        Yes as you may be asked the later question.

Fair enough.

>   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 - except the last one now validates, and the DO bit wasn't set from the stub resolver? (e.g, I won't understand the lack of AD bit)

The simple answer would be to return the three RRSets - but is that the right approach 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 should be "bogus".

The above is different than the secure delegation to an unsecure zone:  The signed delegation to an unsigned zone is controllable by the delegator.  The signed CNAME or DNAME referral to an zone carries no information about whether the referrer/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 (bogus), and returns the data which has no superior trust anchor (unknown), returns the data it was able to validate (secure), and returns the data which was below an unsecure delegation point (unsecure). 

I'm not sure I can argue that a DNAME or CNAME into an unknown/unsecure zone from 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 status at any time after the CNAME/DNAME is published.  Unfortunately, I can't see any way of encoding the DNAME/CNAME signers expectation of security for the target zone in the current definitions.

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 delegations?

Mike

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Sep 2008 16:18:33 +1000

In message <[email-masked]>, Michael StJohns writes:
> 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
> 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

---

From: Michael StJohns <[email-masked]>
Date: Tue, 23 Sep 2008 03:23:48 -0400

>        bogus -> fails validation

 From 4035...

   Secure: An RRset for which the resolver is able to build a chain of
      signed DNSKEY and DS RRs from a trusted security anchor to the
      RRset.  In this case, the RRset should be signed and is subject to
      signature validation, as described above.

   Insecure: An RRset for which the resolver knows that it has no chain
      of signed DNSKEY and DS RRs from any trusted starting point to the
      RRset.  This can occur when the target RRset lies in an unsigned
      zone or in a descendent of an unsigned zone.  In this case, the
      RRset may or may not be signed, but the resolver will not be able
      to verify the signature.

Arends, et al.              Standards Track                    [Page 20]

RFC 4035             DNSSEC Protocol Modifications            March 2005

   Bogus: An RRset for which the resolver believes that it ought to be
      able to establish a chain of trust but for which it is unable to
      do so, either due to signatures that for some reason fail to
      validate or due to missing data that the relevant DNSSEC RRs
      indicate should be present.  This case may indicate an attack but
      may also indicate a configuration error or some form of data
      corruption.

   Indeterminate: An RRset for which the resolver is not able to
      determine whether the RRset should be signed, as the resolver is
      not able to obtain the necessary DNSSEC RRs.  This can occur when
      the security-aware resolver is not able to contact security-aware
      name servers for the relevant zones.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 23 Sep 2008 12:28:27 -0400

I think you're getting too much into the minutia of arguing about how things are done with DNAME if you apply the "rules" and not enough into thinking about whether or not the rules for DNAME need to be different or clarified....

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

Actually, there is a pretty large difference in considering security between:

Insecure:  Someone I trusted told me that data doesn't need to be signed (e.g. secure delegation to an unsecure zone)
and
Unknown: I have no idea whether or not that data should be secure - it's not under a trust anchor *I KNOW ABOUT* - and because of that I can't make useful statement about its actual security.

>        bogus -> fails validation

yeah - we've had this discussion a number of times. If I have no basis on which to make a security determination, it is indeterminate or unknown. In VRR procesing, that generally means the data is passed along with the AD bit off which is no different than the result for insecure data.  The fact the end result is identical from the POV of the querier does not mean the trust states are identical.

With respect to the current problem:

If the middle chain is insecure (e.g. I did CNAME/DNAME into a zone below I trust anchor the VRR has, but that is below a secure unsecure delegation), is this more trustworthy than if the middle chain resolved to an RRSet that had no superior trust anchor?

Again, paranoid's argument suggests that I might consider the former a non-bogus answer and the latter a bogus answer given general DNSSEC principles.

>        is secure (AD could be set if requested) or not.

Agreed, but the current argument is whether or not there is a meta policy that needs to be applied and not just a min() of all of the independent chain results.  What you're identifying is the obvious, but possibly incorrect/insecure approach.

>        Except you can validate that it is insecure.

Actually, you can't.  If the middle chain is not under a trust anchor (or rather if the resolver holds no trust anchor) no validation is possible and an attacker can literally do whatever he wants with the result data.   And the fact of the AD bit being set or not is mostly irrelevant - the end system is still going to see the data.  If the middle chain IS under a trust anchor - there has to be an unsecure delegation for an attacker to get traction.  

The more I think about this, the more I begin to believe that for consistency, if you start under a trust anchor, you better be able to end under a trust anchor and that all chains must be able to be validated/authenticated UNLESS you find an unsecure delegation along the way.    Otherwise you get this weird state where the originator of the data thought he was doing the right thing (a secure DNAME referral into a secure zone), but that the resolver could find itself returning data that was actually bogus (because it was lacking a trust anchor for the referred zone and an attacker got to it).

The tradeoff here is that doing it this way makes the combination of DNSSEC and DNAME or off-tree CNAME less useful.  But what's the right answer from a security perspective?  Do we address this by forcing a resolver behavior, or simply by noting the security issues with off-tree DNAME/CNAME referrals?

I obviously don't think the simple answer is as correct as you think it is.  That's a matter of opinion and the one for discussion.

Mike