Paul Hoffman makes a very important point on section 2 of rfc8624-bis: On Tue, Jan 7, 2025 at 12:18 PM Paul Hoffman <paul.hoff...@icann.org> wrote:
> This set of drafts is a useful addition to the DNSSEC cannon and should be > published as RFCs. > > --Paul Hoffman > > ============================================ > > draft-ietf-dnsop-rfc8624-bis > > The WG should consider whether the publication requirements in Section 2 > are correct. I feel they are not, but I also know that this topic elicits > strong opinions in this WG, in SAAG, and in the IETF in general. > > The guidance the chairs have received is that all new cryptographic algorithms which folks are considering implementing in DNSSEC must go through the Independent Stream (ISE). In specific, I think the bar for all levels should be "publication that > includes the use in DNSSEC", not an RFC. RFCs take a long time to get > through the system, and there is active debate about whether all > cryptographic algorithms should even have RFCs. The extra vetting that a > standards track document requires rarely helps the community understand the > security properties of the algorithm. > I agree with Paul that "RFC Required" and "Standards Action" are a high bar that takes time, which could slow down new algorithms. But at the same time implementers do not wish to be spending developer time on algorithms very few will want, and I agree with them. I will now ask - could we change the requirements in this document to these suggestions? What would be the unintended consequences of simplifying the process hurdles? NewEntry -> MAY => "Specification Required/Expert Review" (Currently RFC Required) MAY -> AnythingElse => "RFC Required/Expert Review" (Currently Standards Action) AnythingElse -> MAY => (Could this even happen??) My personal opinion (which I am confident is universally hated by everyone) is that the "DNS Security Algorithm Numbers" Registry and "Digest Algorithms" Registry should either have a Private Use section for algorithm testing OR make the registries "Specification Required". Simplify the process for experiments with new algorithms. What we care most about is not who likes or dislikes a new algorithm, but > whether there is adequate description of its use in DNSSEC. Thus, saying > "RFC" or "standards track RFC" could still give the registry a reference > that does not lead to interoperability. Non-RFC references that describe > the algorithm and its use in DNSSSEC are better for this community. > > Strongly agree. tim
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
