Paul (and others, so it seems) On Tue, Jan 7, 2025 at 6:05 PM Paul Hoffman <paul.hoff...@icann.org> wrote:
> 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. > > This came up during the 5933-bis Process. https://mailarchive.ietf.org/arch/msg/dnsop/XZoakWUDruPXylJ2wLIS4l4vevo/# Warren wrote up something as well https://mailarchive.ietf.org/arch/msg/dnsop/hv-dlx8rRXHXzB7DMzETLM-Q_vQ/ >> 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. > But doesn't "publication that includes the use in DNSSEC" translate to > "Specifcation Required" or is this something different? > 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. > > I can accept that (I am confident that my bad ideas are bad). But this also sounds like having a section of the registry marked "Private Use" allows for testing with having an official IETF Experiment. My goal here is to help developers, researchers, etc work on new ideas without a lot of process. tim
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
