> 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 > <mailto: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. > 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 > <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-iana-cons-00> > [2] https://indico.dns-oarc.net/event/37/contributions/811/ > <https://indico.dns-oarc.net/event/37/contributions/811/> > [3] https://en.wikipedia.org/wiki/RSA_numbers#RSA-250 > <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
