> On 25 Feb 2021, at 02:01, Ulrich Wisser <ulrich=40wisser...@dmarc.ietf.org> > wrote: > >> >> On 23 Feb 2021, at 17:49, Ben Schwartz <bemasc=40google....@dmarc.ietf.org> >> wrote: >> >> >> >> On Tue, Feb 23, 2021 at 11:21 AM Samuel Weiler <wei...@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: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
