Re: [dnsext] Trust Anchors

[Bob Halley <Bob.Halley@nominum.com>]

On 25 Oct 2009, at 16:30, Paul Vixie wrote:

> if CLOSEST does not match but ANY does, then a system capture in an  
> ancestor
> can introduce trustworthy data about my zones without changing my  
> zone's NS.

It doesn't have to change your NS RRs, but it does have to change your  
DS RRs.

> for example if the operators of COM were to sign (offline) some data  
> about
> SPELLING-ERROR.VIX.COM and sell these signatures to OpenDNS, it  
> would be seen
> as authentic.

No.

RFC 4035 section 5 specifies that trust anchors are used to validate  
keys at the apex of the zone with the anchor's name.

As I understand the standard, COM could not hijack SPELLING-ERROR.VIX.COM 
  without altering VIX.COM's DS RRs.  If COM and VIX.COM were signed,  
a trust anchor at COM would say "start resolutions under COM in secure  
mode and make sure one of the keys for COM is this one".  That would  
establish a valid keyset for COM, and resolution would proceed in the  
usual way down to VIX.COM.  Assuming COM handed out the legitimate DS  
and NS RRs for VIX.COM, then anything in VIX.COM would have to be  
authenticated by one of the keys at the apex of VIX.COM.

So, to be clear, a compromised parent *can* hijack a child, but it  
must do so by altering the DS RRset for the child.  (Where "removing  
the DS RRset and converting the delegation to an insecure delegation"  
is included in "altering the DS RRset".)

Assuming that a validator had anchors for COM and VIX.COM, then here's  
a comparison of ANY and CLOSEST in various scenarios.
"Works" means "legitimate data validates and forged data does not  
validate".

Scenario							ANY			CLOSEST
-----------------------------------------------------------------------------------------------------------------------

Both anchors not stale				Works			Works

COM anchor not stale,
VIX.COM anchor goes stale,
but VIX.COM NS & DS
in COM still good						Works			Fails

VIX.COM anchor not stale,
COM anchor goes stale				Works			Works

Both anchors go stale					Fails			Fails

VIX.COM anchor not stale,
COM compromised,
VIX.COM DS RRs changed
in COM								Appropriately	Forged data
									forged data		never validates
									validates

									True data may	True data
									or may			always validates
									not validate

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

/Bob