> On 25 Feb 2021, at 02:01, Ulrich Wisser <[email protected]> > wrote: > >> >> On 23 Feb 2021, at 17:49, Ben Schwartz <[email protected]> >> wrote: >> >> >> >> On Tue, Feb 23, 2021 at 11:21 AM Samuel Weiler <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
