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

[Wouter Wijngaards <[e-mail]>]

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

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.

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.

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

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

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