Re: [dnsext] Clarifying the mandatory algorithm rules

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Jelte Jansen writes:
> 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.

To roll from one algorithm to another you need to add the new
DNSKEY(s) and sign.  Wait max zone ttl (for all the RRSIGs with
only one set of signatures to clear caches).  Change DS set to
remove the old algorthm and add the new algorith.  Wait DNSKEY TTL
(so there is now no longer a secure path to the zone in any cache).
Removed old algorithm DNSKEY(s) and any signatures made with them.

This is the fastest way to roll from one algorithm to another without
going insecure at somepoint for some validators that support both
algorithms.

You can shorten it (by removing the old DS earlier) but there will
be a time when the zone is insecure for validators that support
both algorithms.

However while this is all happening the validator can be configured
to ignore the old algorithm.  The zone goes immediately to insecure as
far as that validator is concerned on the presumption that insecure is
better than a false secure.

> But I now notice that the current draft for 4641bis says not to do pre-publis
> h
> rollover when switching algorithms, only double signature, so that's ok :)
> 
> 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.
> 
> Jelte
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkzo9dwACgkQ4nZCKsdOncUYfACgokIBu/FP7JTJr1CiPbzHYpvF
> N8MAnihCFpMwL73cWY+/VFl6E+SdqnoI
> =QPR7
> -----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]