On Jan 7, 2025, at 14:30, Tim Wicinski <tjw.i...@gmail.com> wrote: > Paul Hoffman makes a very important point on section 2 of 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).
Who gave that guidance? And, more importantly, why was it given to the chairs and not the WG? This is certainly not what we hear from the Security ADs these days. >> 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. Of course, but this document does not help determine what algorithms anyone will want. For example, if all algorithms must go through the ISE (as stated above), the ISE does not pick which RFCs to publish based on their determination of what algorithms anyone will want. draft-ietf-dnsop-rfc8624-bis as it stands now makes a good distinction: any algorithm can get a MAY-level entry, and it is up to the IETF (hopefully via the DNSOP WG) to determine if that should instead be higher (or lower, if a MAY-level algorithm is determined to be dangerous). In my mind, there is no reason to require that those determinations to be standards-track: they can be informational as long as they are IETF consensus. Again, I don't think that the determinations have to describe the algorithm or its use in DNSSEC. A national standard (such as from NIST) or an academic paper should be fine for getting a MAY-level allocation, and the IETF can follow up with a consensus RFC saying what level beyone "MAY" the algorithm should have. > 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. I'll raise my hand to hating that. :-) The IETF has a spectacularly bad track record for later changing experimental anything into requirements when it becomes clear that the experiment went well. For these tables, having "MAY" mean "we know these things exist, but we don't have any positive or negative opinions on them" is more clear to the developers and implementers than making them guess how well an experiment is going. >> 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. --Paul Hoffman _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
