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

[Michael StJohns <[e-mail]>]

At 03:30 AM 10/23/2008, Wouter Wijngaards wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Michael,
>
>You can propose some new mechanism here, but do not overload the DS
>semantics more. Get a new type code, like DLV did.

Fair - but the the new record will pretty much have the same syntax and semantics. 

>That said, lets sling some mud :-)
>
>Michael StJohns wrote:
>> At 11:43 PM 10/22/2008, Mark Andrews wrote:
>>>> 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.
>>>>
>
>So you want the owner of the DNAME to indicate if he is referring to a
>secured zone or not (using a hash of a key).  And the validator can then
>check if the destination is really secure.  This needs only one bit:
>target of redirection is supposed to be secure yes/no.

I considered this - but that means that you need to ensure that all the resolvers have the second and subsequent trust anchors and that's problematic.  Encoding the chain of trust as part of the DNAME referral means that I as publisher don't have to worry (much) about whether or not the resolver has my target's trust anchor.  

>The chain of trust runs parralel to the delegation hierarchy, and I
>think sideways chains of trust need not enter the picture here.  Not for
>your DNAME concerns.
>
>Although the above is what I think you want.  I think the current DNAME
>situation is fine.  The resolver can see if the target of a DNAME
>redirection is secure or not based on trust anchors, and is going to set
>the security result of the entire DNAME-chain to the lowest security
>encountered anyway.

Yeah, except there's no way of encoding this in a return from a validating recursive resolver to a non-DNSSEC aware stub.  The one bit approach that tells the resolver to block a return unless the entire answer validates (or is securely unsecure) is slightly better, but gets into a coherence issue.


>>>> 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.
>
>Yeeks how to keep that DS up to date.  Better one bit: target secure, it
>does not suffer from key rollover.

If I'm DNAMEing to a zone, I'm going to have to set up some protocol for dealing with changes to that zone.  A variant of the trust anchor update stuff would work here.


>>>> 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.
>
>I agree with Mark here.
>
>> 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.... :-) 
>
>No.
>
>You see when a validator encounters a securely-insecure delegation, I
>mean a proof that a DS is absent.  Then it knows that the remainder is
>not signed with a chain of trust from the trust anchor that it has been
>following.  However, the result is simply insecure, and not somehow
>magically more secure that a result obtained without a trust anchor at
>all.  What is the extra security afforded by a securely insecure
>delegation?  The result is as prone to modification as a result obtained
>for a domain without trust anchor.


It's a fair comment.   Here's why I continue to fight this.  A trust anchor provides two pieces of information:  a public key, and by the mere presence of the trust anchor the initial state of a virtual "zone is signed" bit.  The absence of the trust anchor does not equate to "zone is not signed" but to "resolver doesn't know whether the zone is signed"

Think of it this way, the unknown state is like the X state in ASIC circuitry design.  You may end up treating it as a 0 or 1 at some point, but you have to figure out a way of collapsing it to the 0 or 1 first.  Resolvers basically collapse the X to a 0 - unsecure - because they don't have the ancillary information (trust anchor) to treat it as a 1.  The resolver doesn't know if the zone is signed, but it has no way of proceeding unless it treats the zone as unsigned. The transition from X to 0 is not secure - there's no cryptographic proof to do the state setting.  This differs from a secure transition from secure to unsecure - from 1 to 0 - by doing a signed delegation to an unsigned zone.  

I actually can at some point see some policy wonk requiring that resolvers under the wonk's control will not resolve names unless they are under a trust anchor.  He won't care about the fact that some delegations are to unsecure zones - he's just concerned about getting DNSSEC deployed.  So yes - I still think there's a difference.


While I was going through this exercise of answering your email, Ben's and Ed's I came up with a pretty good example of why I think this (chaining through a DNAME) is necessary.

I work for the example.com company.  My local recursive resolver has been set up with example.com trust anchors.  The example.com zone includes a set of records which describe the SSH fingerprints for those machines.  example.com is sold to otherexample.com and a DNAME record is placed into the system to do the redirect.  My local resolver still only has the trust anchor for example.com.    I go to a new machine asking the "newmachine.example.com" question to retrieve the SSH fingerprint (I'm an old timer - I'm still using old scripts).  I get an answer for the SSH fingerprint and for an A record - which has been cheerfully forged by a data thief.  I go to that machine, update the 10 gig of ssn's, names and birthdates that I'm archiving from a machine I'm about to rebuild.  That machine is somewhere in russia, china, new york, etc... and its not a company machine.

Out of band, I (person, machine whatever) was told I could rely on the data returned from the resolver for security purposes.  (And this is why I've told people over the years that DNSSEC should not be relied upon to validate anything other than DNS data).  My machine was set up with that assumption in mind.  The local resolver is doing what its supposed to do under the current DNAME interpretation.  My machine is doing what it is supposed to do with the data.  But I got screwed.





>Of course, the two domain set ups have a different operational
>configuration.  So although you can give them different names (which can
>be useful for other things, such as operator debugging), they have the
>same level of security.
>
>>>> Let the mud slinging begin... :-)
>
>Cheers,
>   Wouter
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.9 (GNU/Linux)
>
>iEYEARECAAYFAkkAKB4ACgkQkDLqNwOhpPin2gCgtHuA1I2S/+Gok9TQ3BNnN7Pw
>Z+MAn2YAD/HLWriLwP0y2+q55FScRfW8
>=nwDQ
>-----END PGP SIGNATURE-----
>
>--
>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/>



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