[Dnssec-deployment] cases - was Re: Barbie sez: "Algorithm rollovers are HARD!"

Jelte Jansen jelte at isc.org
Tue Aug 17 10:40:44 EDT 2010


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

On 08/17/2010 04:17 PM, Edward Lewis wrote:
> 
> I see.
> 
> The problem is that the specification is not conveying the right
> message.  (I know because I was heavily into the crafting of the
> requirement.)
> 

Right. In retrospect this is what Mark tried to say back in '08 in response to

http://www.ietf.org/mail-archive/web/dnsop/current/msg06707.html

which I never really understood until the issue came up again at the last IETF.

>
> Cases II and VIII, the cases where a cache has many algorithm keys for a
> zone yet sees just one useful signature should result in a thumbs up in
> validation.
>
> Implementors may feel that's too loose, but it was what was meant in the
> design of the protocol extensions.  To clean up the specification, it
> should be emphasized that although the signer is supposed to supply one
> of every signature, the validator only needs one working signature to
> okay the data.
>

Thing is, that's not what the spec says; it does say so for multiple signatures
with the same algorithm, but section 2.2 seems pretty clear on multiple algorithms.

So there's this difference between what the spec says and what it means, and
only the ones who originally wrote the specific parts know the latter.

There are validators that check this, and there has been at least one TLD that
fell off the map because of it.

It does not really help from an operators point of view that there are other
validators that do what the spec 'means'. So we need the current text either
confirmed or fixed. And in the latter case, deal with validators that implement
the current RFC.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxqn2sACgkQ4nZCKsdOncWJzQCgvDLNRPWxjAFPuUbtfkJ6lGr0
EEgAoMTKCrQbpHj+CSGOZWg0EwJ4gnC3
=s99p
-----END PGP SIGNATURE-----


More information about the Dnssec-deployment mailing list