No hat.
On Tue, Oct 27, 2009 at 09:41:41AM +0100, W.C.A. Wijngaards wrote:
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.
[â]
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.
For me, at least, all that the changes to dnssec-bis-updates should
say is that, if there are two paths for a validation of a given name,
using different trust anchors at different distances in the tree,
either one is as good as any other. You are, however, pointing out a
nasty consequence of the current proposal: when the closest TA does
not validate, and a distant TA does validate but there is an
intermediate zone that is unsigned, you move the target domain from
"bogus" to "insecure". I think this is a good point (but I didn't
understand what you were saying until this message. Sorry I'm so
thick).
Now, what bothers me about saying, for simplicity's sake, "Do
CLOSEST," (because the real issue is too hard to explain or
understand) is that we are almost guaranteeing false failures by
picking "CLOSEST". The usual response to this concern is, "Yes,
people have to be super-competent in operating their zones during
DNSSEC adoption." To me, that position flies in the face of all our
experience with the actual operation of the DNS. We know that there
are plenty of zones out there that are operated quite badly without
DNSSEC. We're asking either that, overnight, all those human errors
go away, or else that people accept that they have to trade
unreliability to get the security we are trying to sell them.
I believe that what will happen, if we stick with CLOSEST, is that a
number of domains will have nasty experiences with DNSSEC. The report
that ends up going to management when each outage happens will be,
"Due to DNSSEC, our domain became unavailable to CustomerC from
$starttime to $endtime." Management in each case will say, "How much
do we need this DNSSEC anyway?" Since the advantage of DNSSEC to the
publisher of the DNS data is not that great, the incentive will not be
strong to continue using it, and pretty soon this useful technology
will get a reputation as another complicated, doesn't-work thing that
should just be turned off.
Finally, the argument that there is an important downgrade available
under ANY depends on the premise that, in validating cases, there is a
valuable difference between "bogus" and "insecure". Mike StJohns has
argued strongly that, for practical purposes, if you are really going
to check validation you're not going to care what the reasons are that
something doesn't validate. If that's right, then there is no
_practical_ downgrade path here anyway. I don't know whether he's
right, however.
I therefore think that we ought to work on text that makes it clear
that the postive-validation paths are all just as good as one another,
but that a good security policy might prefer bogus over insecure paths
in case postive validation is not at all possible.