On Apr 30, 2024, at 16:20, Wes Hardaker <wjh...@hardakers.net> wrote: > 3. The whole discussion, IMHO, is side-stepping the real issue: if not > now, then when? IE, do we never put something at MUST NOT? Is there a > usage threshold? Is it "must be zero"? Is it "known to be broken and > everyone must have a flag day instead of a slower process"? > > These are not easy questions, and there does seem to be many different > opinions. RedHat led the pack(ish), and maybe Paul and others will be > the tail end at some very late value. There is no right or wrong, and > the line of people are likely to spread out along the timeline.
Thank you for asking the question about questions. But, please, don't simplify with the phrase "MUST NOT" given that the draft has that for two different parts of the DNS: signers and resolvers. My personal feeling is that "MUST NOT sign because RedHat" is an unfortunate position for us to be in, but one that is defensible. "MUST NOT validate because of some security issue that might never happen" is not defensible, at least to me. The argument "you signing something that we know many resolvers cannot validate is actively bad for security" is defensible. Until someone can show that a reduction in collision resistance can lead to a reduction in real-world security for DNSSEC, we can wait for "MUST NOT validate", possibly forever. There is no good reason for this group to say to a zone operator who signed their zone in good faith "we are now making your zone insecure"; it's even worse for us to say to zone owners "we're forcing you to pick a different TLD if you still want to be secure". And, to be clear: I don't support waiting for a usage threshold for "MUST NOT validate". If there is any noticeable chance that an attacker can create a key or signature for a zone they don't control, that is a good enough reason to go to "MUST NOT validate" and let the resolvers decide if they want to be compliant with the new standard. But we aren't there yet, and when we are, the RFC needs to say how we got to that conclusion. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
