Re: [dnsext] Trust Anchors

["W.C.A. Wijngaards" <wouter@NLnetLabs.nl>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/26/2009 05:27 PM, Paul Hoffman wrote:
> +1. The IETF has seen this kind of feature creep in other security protocols, and the end result is always unexpected behavior for the relying parties. Even in protocols where degrees of trust were built-in from the beginning, namely PGP, the use of degrees were mostly abandoned by users or, worse, used without understanding.

So its fine to put the anchors on an equal 'security' footing.
For the digital signature part.  The name in it does signify that
the operator wanted that name to be dnssec secure.

Now allowing that name to become secure using another key is fine with
me, but to stop possible downgrade attacks you really have to include
some language that says, for ANY, that if one anchor fails and another
is attempted, that the resulting chain of trust should securely reach
the original closest anchor.

So that, although you may use the root .com or example.com key
to validate www.example.com, the name 'example.com' was secure in
the chain of trust.

It is then a protection against some stale key for example.com
But that does not mean that example.com is allowed to become unsigned.

I realize this likely defeats some amount of the trouble we
try to save the operators here, because that stale key now prevents
rollover to unknown algorithms, the domain to change hands and then
become unsigned, ...

Many reasons to configure such anchors are exactly, say that example.com
is signed, but .com is not, and the root is.  The ANY mechanism allows
the security to be downgraded by spoofing for example.com, which is why
I attempt to get some extra language about covering the domain name of
the closest anchor with a secure part of the chain (I mean, not
unsigned).  And I am spending a lot of words on it, because people say
this is confusing.

It is not degrees of trust I want, but rather to avoid downgrades:
CLOSEST is simple, simple to understand, and very secure.

Configuration that makes certain trust anchors applicable only to
a particular part of the DNS tree - in high detail for security
minded people - should not be ruled out, I think.  Does scoping
keys create such (evil) feature creep with degrees of trust in it?

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrmskUACgkQkDLqNwOhpPjAGQCfa3yCyU1IuUPe5O6iz6nN8I7b
zL8AoKzKg0yGe6j6TXkF0TRcDw5lLORq
=+Bs5
-----END PGP SIGNATURE-----