Eric: > On Apr 2, 2026, at 6:47 PM, Eric Rescorla <[email protected]> wrote: > > On Thu, Apr 2, 2026 at 3:25 PM David Benjamin <[email protected] > <mailto:[email protected]>> wrote: >> I think trying to cite IANA registries is a distraction. IANA registries are >> not enough. To meaningfully define a codepoint, you need to say what the >> codepoint means. That's why our IANA registries have document references. >> Moreover, to be well-defined, it needs to be a TLS-specific document, not >> just the underlying crypto, to write the small handful of TLS-specific >> definitions needed to glue things together. >> >> Now, those documents are candidates for citing, and our registries do >> sometimes reference drafts, as they do here. One could argue that people >> should just be OK citing drafts. But I cannot entirely blame folks for being >> reticent to cite drafts when the IETF spends so much energy to emphasize >> that drafts are not done. They have expiry, there is no indication whether >> people expect to define a new one with different semantics, etc. For things >> that the IETF does intend to publish, we have all spent quite a lot of >> energy making sure people downstream of us know that it's not "official" >> until it's published. We all did this because it's harmful for standards >> work if people freeze intermediate snapshots that aren't done. > > ISTM that the "freezing" here happened at the time of code > point assignment.
I agree with the points made by David Benjamin. I will further emphasize that IANA registries for algorithms include a pointer to a document because there are almost always things that need to be said to achieve interoperable implementations. Even with simplie AEAD algorithms, the key size and the authentication tag size need to be nailed down. > >> We can't have it both ways. Either we tell everyone that drafts are >> perfectly fair game to implement, with no stopgap against people >> inadvertently ossifying things that aren't yet done, or there must be ways >> for drafts to progress into a state that signals they are done. That durable >> state doesn't have to be an RFC, but it's the only one the IETF has defined >> right now. >> >> One could say, ah, the problem is the IETF needs to define a non-RFC end >> state, and that that's not TLS WG's business. But it is very much the TLS >> WG's business that we're worrying about this at all, because we've managed >> to spend a disproportionate amount of time waffling on technically trivial >> documents. > > I don't think that this analysis is really correct. > > Stepping back from this document, we have roughly two categories of > algorithms (and other extensibility points): > > A. Those which have the support [0] of the TLS WG. > B. Those which do not have the support of the TLS WG but some set > of people nevertheless wants ot use. > > Type A algorithms get published as RFCs. > > The current registry structure was designed to allow people with Type > B algorithms to nevertheless reserve code points without the TLS WG > getting involved, either on the basis of some non-RFC specification or > by persuading the ISE to publish their RFC. The reason we did this is > not because we want to promote the use of those algorithms but rather > because we know people will use them anyway and we want to avoid > contamination of the code point space. This characterization is too simplistic for the global internet. I am not talking about consensus, but the reasons that algorithm documents are published by the IETF. Interoperable implementations is the goal, and detail need to be written down to achieve that goal. Once there is consensus that the details have been accurately captured, the document can get a code point assigned. In my view, the document should become an RFC for at least three reasons. First, Internet-Drafts are a work in progress. We used to take expired I-Ds off the web site, but that made diff tools essentially useless. So, other people kept archives of old I-Ds. When I was IETF Chair, we changed that policy so that the I-Ds were available for the diff tools. That turned out to also help with IPR searches. I believe that was a good decision, but I-Ds are still a work in progress. As a result, they should not be cited by other SDOs. Second, organizations want to buy interoperable implementations. When someone wants to purchase an TLS 1.3 implementation, they cite RFC 8446. Interoperability is improved when it is equally simple for them to cite documents for the non-mandatory-to-implement algorithms that are desired. It is important to deploy more than one algorithm so that configuration changes can implement a transition when confidence in a particular algorithm dwindles. Third, algorithms age. The IETF has struggled with explaining the algorithm lifecycle. A few of us wrote draft-crocker-dnsop-dnssec-algorithm-lifecycle in an attempt to explain ii in the DNSSEC context. Not all algorithms that get specified will become mandatory to implement. That is completely appropriate. However, the IETF needs a way to tell implementers which newly specified algorithms are raising in confidence and are likely to become mandatory-to-implement in the future. Likewise, the IETF needs a way to tell implementers which specified algorithms are fading in confidence and are likely to become no-longer-mandatory-to-implement in the future. Jeff Schiller introduced SHOULD+ and MUST- for this concept with IPsec algorithms in RFC 4307, but this convention has not been adopted throughout the Security Area. In the TLS WG, there has been no attempt to include this kind of information in the documents, which would be very helpful to product planners. I believe it should be done by citing the algorithm documents, not repeating algorithm details in different places where it talks a lot of careful review to determine if all the the details are the same. > Now, sometimes, as in this case, we get people who want to use an > algorithm ask the TLS WG to publish an RFC because they don't want to > use the code point without an RFC. However, the reason these documents > aren't being published as RFCs is because there's not consensus that > have consensus promote their use, so I don't think publishing them as > an RFC so that others can more readily use them is a very strong > argument. If people find it somewhat harder to use algorithms for > which there isn't consensus why is that bad? I think you are mixing two things. Is there consensus that that document accurately captures the details for using the algorithm in an interoperable manner? If so, then I believe that the document should move forward so that the people that want to use that algorithm can do so. Is there consensus that the TLS WG wants to promote the use of the algorithm? If so, then I believe that document and the IANA registry should reflect that consensus. The IANA registry will say Recommended=Y. Of course that will change over time because algorithms age. > With that said, if we want to make a shift like that contemplated > draft-barnes-tls-this-could-have-been-an-email, such that even > documents which the WG does feel positively about and otherwise could > have gotten consensus to publish as RFCs are just I-Dsor emails, then > we perhaps do in fact need some permanent definition of the algorithm, > but that doesn't seem to be the case here. I addressed this above. Internet-Drafts are a work in progress. Russ > [0] By support I mean "enough people in favor that they can be > published in the IETF".
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
