On Thu, Apr 2, 2026 at 6:48 PM Eric Rescorla <[email protected]> wrote:
> On Thu, Apr 2, 2026 at 3:25 PM David Benjamin <[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. > Not quite. Assigning the codepoint means that 0x0201 forever means draft-ietf-tls-mlkem-07's ML-KEM-768 construction. It does not mean that we won't publish draft-ietf-tls-mlkem-08 to define 0x0203 for a slightly different ML-KEM-768 construction. Now, there is barely anything (but still something) to define in draft-ietf-tls-mlkem, so this is obviously not going to happen here. But, in general, we have lots of things to fiddle with when defining things. TLS 1.3 and ECH went through a number of codepoints, each of which meant particular drafts, but we were not ready to call it done for several codepoints. > 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. > > 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? > > 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. > What's missing here is that publication can potentially signal one of two things: - Whether the TLS WG promotes its use (though we also have the Recommended column) - Whether the community of folks who care about that scheme are done with it RFCs, in different contexts, are used for both, which unavoidably causes some tension. -Ekr > > [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]
