Re: [dnsext] Clarifying the mandatory algorithm rules

[Matthijs Mekking <[e-mail]>]

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

Hi,

On 11/21/2010 11:35 AM, Jelte Jansen wrote:
> On 11/19/2010 02:16 PM, Mark Andrews wrote:
>>>> If a algorithm is insecure then you should remove it from the list
>>>> of acceptable algorithms in you validator.  That way you get insecure
>>>> not trusted out of the validator.
>>>>
>>>
>>> If you do that, and the zone(s) do 'normal' pre-publish rollover from
>>> that broken algorithm to a not-yet-broken one, you'd get bogus, not
>>> insecure, during the roll
>>>
> 
>> No you don't.  Once a algorithm is marked as invalid the validator
>> behaves exactly as if the validator doesn't know about the algorithm.
> 
>> During the pre-publish period there isn't a trust path into the zone with
>> a supported algorithm.
> 
> 
> no, but during the DS switch there would be, same problem, just a different level.
> 
> If it is the DS set that specifies which algorithms are used, you either have to
> have both algorithms in that set at one point, or have the zone fully signed
> with both algorithms. But if you have both DS's in there, and the zone itself
> signed with only one, it'll be bogus for validators that only support the other
> algorithm.
> 
> But I now notice that the current draft for 4641bis says not to do pre-publish
> rollover when switching algorithms, only double signature, so that's ok :)

Actually, you cannot even do pre-publish algorithm rollover. In order to
introduce the new algorithm at the parent, you need to fully sign your
zone with that algorithm. Effectively, it becomes a double-signature
rollover.

> The part about adding signatures first could probably be removed if 4035 is
> clarified (changed, depending on one's POV ;) ) that it is the DS set and not
> the DNSKEY set that one should check for algorithm support.

You would still need to pre-publish signatures if you want to support
RFC 5011 (because you have no method to delay adding this trust anchor
until the zone is fully signed with the new algorithm).

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

iQEcBAEBAgAGBQJM6i+NAAoJEA8yVCPsQCW5SnEH/j/gAYWS9xf2+zqgdXHMhTrx
LHFYQR5HF9SLxmG2gd6HaZ9WpBPge7gTVcnUhP9A7/VLl0LjZdfC83/XFam/X1wZ
twl4HU6wxwJoVp7xffJKGQkV2by2RUy2Wt+Tz3lY3B0YTGkPC66567Mm/WK/xYT2
bSUTXaePkrFKuo1d6sg+tM9t14lCBLKoWL79p15UteKm7klIfVCeeVZSm35Rbug0
XaeSeA3nmlAEAvj24mk1aNCZqZWEjp5zGHKT185Kzrf7sGtxwId5wHto+6y+T58b
FYEx2f9hBkr6Ww3jMeSNa8DawDx5dUvQKCwwKP8H4//iyg/7SWHb3ksbZ4aHivM=
=xVvl
-----END PGP SIGNATURE-----