Re: [dnsext] Clarifying the mandatory algorithm rules

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Matthijs Mekking writes:
> -----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 ha
> ve to
> > have both algorithms in that set at one point, or have the zone fully signe
> d
> > with both algorithms. But if you have both DS's in there, and the zone itse
> lf
> > signed with only one, it'll be bogus for validators that only support the o
> ther
> > algorithm.
> > 
> > But I now notice that the current draft for 4641bis says not to do pre-publ
> ish
> > 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 n
> ot
> > 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).

Unless the max zone ttl is greater than the Add Hold-Down timer (min 30 days)
this is a non-issue.

Mark
 
> 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-----
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]