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

[Michael StJohns <[e-mail]>]

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


At 02:18 AM 9/23/2008, Mark Andrews wrote:

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

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.


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

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.


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

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.

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

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



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