Re: [DNSOP] [Ext] DNSSEC Strict Mode

> On 26 Feb 2021, at 04:39, Paul Wouters <paul@nohats.ca> wrote:
> 
> On Feb 25, 2021, at 11:06, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
>> 
>> 
>> 
>> That's not especially the intent.  Currently, if you sign with two algorithms, and either of those algorithms becomes insecure*, your zone becomes susceptible to forgery.
> 
> Which is why we have RFC 8624 and it’s successors. It really should prevent you from using “insecure” or weak algorithms. The [*] doesn’t really help you. If sha2 is broken and we don’t know it, you wouldn’t know to not use it as “secure”
> 
> 
> 
>>  If you mark both algorithms as Strict, then your zone remains secure (for validators who implement both algorithms and this draft).
> 
> That cannot be true, unless your draft requires validaties to validate with all algorithms for a double signed zone (also double signed zones are rare and really only transition during a migration)
> 
> I’m with Paul H here, I don’t see a use case.
> 
> As I think Petr said, we need to make the software do algorithm rollovers easier so people don’t avoid migration.

And the first thing to do is to stop saying “Roll DNSSEC Algorithms”. You are adding a new algorithm then dropping the old algorithm.  TLD operators made this sound dangerous.  They created the myth that it is hard to do.  Every signed zone in existence “added a new algorithm” when they signed their zones for the first time.  Trying to do the two things at once complicates things.

Add a new algorithm:

Create keys for the new algorithm.  Start signing the zone with them.  Wait a while for any old DNSKEY RRsets (or the negative cache when signing the first time) to expire from caches.  Add DS records for them.

Remove a algorithm:

Remove DS records for the algorithm.  Wait a while for the DS records to go from caches.  Stop signing the zone with the algorithm and remove the DNSKEYs and associate RRSIGs.

Thats it except when there are trust anchors involved like for the root zone.  You add trust anchors last and remove them first.

> 
> Paul
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org