Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME

[Michael StJohns <[e-mail]>]

At 11:43 PM 10/22/2008, Mark Andrews wrote:

>In message <[e-mail]>, Michael StJohns writes:
>> 
>> After thinking about this topic for a while, I'm still bothered by the incons
>> istency of treatment here.
>> 
>> But I think I have a possible mechanism - at least for DNAME.
>> 
>> DNAME is the pretty much the equivalent of a delegation - only sideways.    W
>> hy not treat it like any other delegation?  In other words, in addition to th
>> e records currently permitted at a DNAME node, add DS to the list.  This woul
>> d require slightly overloading the meaning of DS, but in a way that doesn't b
>> reak the model too much.
>> 
>> If a DNAME node does not have at least one corresponding DS record (proven by
>> NSEC/NSEC3), the validation rules are exactly the same as if you'd not inclu
>> ded a DS for a subordinate delegation. E.g. no DNSSEC is expected in the targ
>> et zone.
>> 
>> Since one of either DNAMEs or NS records can be present at a node (I think th
>> at's correct), the interpretation of the DS record is dependent on which of t
>> hese two is present.  If the type is DNAME, the DS record points to a DNSKEY 
>> record at the target name and the chain has to continue from there.
>
>        So I create a DNAME pointing into a zone I don't own and
>        add a DS pointing to a forged DNSKEY.  This DNSKEY is then
>        marked as trusted and I now have control of a zone I don't
>        own.

I think you're confusing how you might implement this with what I actually said.

When doing this, you have to do the analysis first for the non-cached approach.  Where you do all the validations and lookups from the beginning.  THEN think about how you cache the data to keep from polluting trust states.

For caching, you only mark the apex DNSKEY (and its subordinate data) of the target zone as trusted ONLY for queries that are referred in via the off-tree DNAME and DS.  If you come at it any other way you don't trust the data unless you have a superior trust anchor.  (Yup I know - more cruft, but relative to DNSSEC probably not a great portion of the cruft).

 Let's say the recursive validating resolver doesn't have a superior trust anchor for the target - a direct query for the target gets the data with an output state of unknown/unsecure.  An indirect query via the DNAME - assuming the target is signed and the DS chain validates - has the possibility of getting data with an output state of secure - or for that matter bogus (in which case no data or partial data is returned).

If you do have a configured trust anchor for the target zone and that validation doesn't match the DS referral from the DNAME - well - that's probably one of the BOGUS cases.  If you don't have a configured trust anchor for the target zone, umm... then the owner of the DNAME can steer you pretty much wherever he wants - even a zone that's somewhere that doesn't have a trust anchor so how is this worse?

You are correct that if you implement this so the resolver takes the indirect trust and caches it as absolute trust then the owner of any DNAME under any trust anchor can pollute the trust cache on that resover.  So don't implement it this way.... 




>> This gets away from the problem where a resolver has one trust anchor, but do
>> esn't have a trust anchor for the target zone at the cost of requiring some a
>> dministration of the DS at the DNAME.
>>
>> Continuing the logic from above, if you get a unsecure DNAME delegation (i.e.
>> DNAME without DS), you *stop* doing DNSSEC validation.  It doesn't matter if
>> you have trust anchors for any further targets - the validation answer is UN
>> SECURE.  This is required for consistency - different resolvers have differen
>> t sets of trust anchors.  It's not all that coherent to get BOGUS from one, U
>> NSECURE from another and UNKNOWN from a third if you can avoid it.  Chaining 
>> security back to the original trust anchor and evaluating security in terms o
>> f data that chains back ONLY to that trust anchor seems to be the most consis
>> tent approach.
>
>        There are only three possible outputs from a validating resolver.
>
>        The *all* of the answer and authority sections are SECURE (ad=1).
>
>        All of the answer and authority sections passed validation (got
>        SECURE or INSECURE) and some part was INSECURE (ad=0).
>
>        Validation failed for some part and you get SERVFAIL.
>
>        There is no UNKNOWN output.  Records without a trust anchor are
>        INSECURE.


There's a difference between the output from a validator and the output from a validating resolver - but I digress...


We're just going to have to agree to disagree.  I can distinguish between data where I have no information about its trust state (it might be signed, but I have NO trust anchor so I have no way of determining whether it is secure unsecure or bogus) and data where I have information about its trust state (because I have a trust anchor and I was able to run a validator and return one of secure, unsecure or bogus on the provided data).   That difference may or may not be important to an end-application validator - but I'm not willing to exclude it from consideration at this point.  So mentally from now on just substitute UNSECURE wherever I say UNKNOWN and I'll consider the protest given proforma.... :-) 



> 
>> In any event, I think this is at least somewhat backwards compatible. 
>> 
>> Let the mud slinging begin... :-)
>> 
>> 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/>
>-- 
>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/>