Re: [dnsext] Trust Anchors

[Paul Vixie <vixie@isc.org>]

> From: Bob Halley <Bob.Halley@nominum.com>
> Date: Sun, 25 Oct 2009 11:27:06 -0700
> 
> No.

thanks for explaining this.

> Supporters of ANY worry that during transition to DNSSEC you will set up
> your validator with a VIX.COM anchor, because COM is not signed yet.
> Later COM will be signed, and you'll add an anchor for it and forget to
> remove the VIX.COM anchor.  If the VIX.COM anchor goes stale, under
> CLOSEST your resolutions will fail, whereas under ANY they will not.
> 
> Supporters of CLOSEST argue that the detection of a compromise or other
> problem in the parent is good security.
> 
> I'm sympathetic to the problems of staleness that ANY supporters worry
> about.  By my prior sysadmin experience tells me that if I configure
> VIX.COM and COM both as trust anchors on my validator, and use ANY, than
> one of them will go stale and I'll not notice, and then when I'm on
> vacation the other one will go stale, and resolution will fail, and I'll
> get emergency phone calls.
> 
> I'd rather we kept CLOSEST for its security benefit in the compromise
> case, and tried to tackle anchor staleness directly (via RFC 5011 or some
> other means).

i get it.  i do not think the standard should address the multiple ancestor
problem since this is a configuration detail.  this could mean simply not
specifying the behaviour if there are multiple static trust anchors all
covering the signature that you're trying to validate.  but if we're going
to talk about multiple enclosing static trust anchors, i'd rather we say
that the closest one has to match and the others aren't looked at at all,
then to say any of them can match.  the RFC could also say that multiple
enclosing static trust anchors are a bad idea, and if they are configured
then the software should syslog a warning about it, early and often.