Re: [DNSOP] [Ext] DNSSEC Strict Mode

> On 25 Feb 2021, at 02:01, Ulrich Wisser <ulrich=40wisser.se@dmarc.ietf.org> wrote:
> 
>> 
>> On 23 Feb 2021, at 17:49, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
>> 
>> 
>> 
>> On Tue, Feb 23, 2021 at 11:21 AM Samuel Weiler <weiler@watson.org> wrote:
>> ...
>> Recognizing that I'm likely biased by my history of working on the 
>> current "mandatory algorithm rules", I don't buy the need for this 
>> complexity.  In practice our "weak" algorithms aren't _that_ weak. 
>> And, if they are, we might as well stop signing with them entirely.
>> 
>> I think that was true for a long time, but I'm not sure it's still true, or will stay true.  I'm particularly motivated by the ongoing discussion about adding Algorithms to the registry [1], and a recent overview of Post-Quantum cryptography for DNSSEC [2].  Also, 829-bit RSA was factored last year [3].  Validator update timelines are Very Slow, so we should be thinking about adding features we might need before we need them.
>> 
>> Even if we are currently in a state where zone owners feel like they have simple, safe choices, I don't think we should assume that this will remain true indefinitely.
>> 
>> This seems like unnecessary further loading of the camel.
>> 
>> FWIW, my preference would be to simply remove the lax-validation rule from RFC 6840, which would simplify the standard overall ... but there must have been a good reason for it.  Strict Mode might be a stepping-stone in that direction.
> 
> Not only am I in favor of the RFC6840 lax validation, it is in fact necessary for secure DNSSEC operation.
> In fact I believe the RFC 4035 needs to be updated to explicitly allow algorithms without signatures.
> At the current state of dnssec RFC definitions it is unclear how you could change DNS operators securely if these operators do not sign the zone with the same algorithm.

You can’t do that as the logic doesn’t allow it.  Perform algorithm roles to and from mandatory to implement algorithms before and after the move if necessary.

>> Ben, if you decide to persist with this idea, I've filed some issues 
>> in your GH repo.
>> 
>> Thanks! 
>> 
>> [1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-iana-cons-00
>> [2] https://indico.dns-oarc.net/event/37/contributions/811/
>> [3] https://en.wikipedia.org/wiki/RSA_numbers#RSA-250
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> 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