As another data point on this, the following is a direct quote from the UK NCSC’s guidance on PQC migration:
> These algorithms will need to be implemented in protocols before they can be > used on the internet and in other networks. The IETF is in the process of > updating the most widely-used security protocols. This includes ensuring that > PQC algorithms can be incorporated into key exchange and signature mechanisms > in existing protocols such as TLS and IPsec. IETF implementations of > post-quantum protocols are subject to change until they are published as > RFCs. The NCSC strongly advises that operational systems should use protocol > implementations based on RFCs, not on Internet Drafts. https://www.ncsc.gov.uk/whitepaper/next-steps-preparing-for-post-quantum-cryptography, (emphasis theirs) I have a mild preference for not spending lots of time on every possible code point that people might require, but I do strongly feel that we need an “end state” for “this-draft-exists-just-for-a-code-point” that is better than “expired I-D”. Otherwise we’re not believable to external SDOs and regulators. Regards, Thom Wiggers > Op 2 mrt 2026, om 18:13 heeft David Benjamin <[email protected]> het > volgende geschreven: > > > That the endorsement of the IETF matters to so many continues to surprise > > me. Not a whole lot, but the way that symbolic measures like this act as a > > substitute for good judgment is one of the great mysteries. > > I'd echo Ben's comments earlier in the thread. While there are certainly > silly reasons, the reason Ben cites is more than symbolic. For someone > implementing and deploying something, an immutable codepoint isn't > sufficient. It's also important to know that the feature is "done" and that > the TLS community isn't going to next week define a new codepoint that flips > the order of the key shares or whatever. (E.g. the many iterations that led > to the final version of ECH.) > > This is critical for the health of the TLS ecosystem. Sure, the big > deployments and early movers can move fast, ship experiments, unship them, > etc. But if we want TLS to be accessible to the broader internet, we need to > keep others in mind. Others are less able to unship things they once shipped. > But if every draft iteration of ECH had to survive in TLS libraries because > people can't unship them, we would never get anywhere. That means there's a > crucial milestone when a TLS feature is safe to ship in more durable > contexts, and we need to actually be able to get to those milestones. > > For that to happen, for TLS to serve more than just the major players, the > TLS community needs a venue to coordinate on work, roughly agree on when this > milestone has been reached, and actually reach that milestone. Historically, > that venue has been the TLS WG. > > Moreover, when the milestone is reached, there also needs to be a clear > indication of this. Those of us here, paying attention to the group and > sifting the through the atmosphere, know the status of things. But TLS > touches more people than this group. I work with many, many groups who > integrate TLS into their projects. They have the rest of their project to > worry about and can't follow the WG. But they need to know, when evaluating > X, whether X is ready or not for them. Historically, that indicator has been > document publication. > > All this is certainly imperfect, even historically. (E.g. the long time > between something being "done" and a final RFC increases the window of > uncertainty for folks. And of course this venue can be a bit abrasive.) > Unfortunately, this WG has trended even more towards those imperfections, so > here we are. These kinds of cryptography drafts seem to be the extreme case, > where there is some coordination needed, but it is minimal in comparison to > the problems it triggers here. > > Perhaps this WG needs to have fewer responsibilities, as this draft suggests, > before it can reverse this trend. But that won't change the need for the > coordination work somewhere, and I don't think we should be proud of > producing an atmosphere where we need to actively drive that work to other > venues. > > On Mon, Mar 2, 2026 at 8:46 AM Salz, Rich <[email protected] > <mailto:[email protected]>> wrote: >> - TLS Exporter Labels >> - TLS SSLKEYLOGFILE Labels >> - TLS Certificate Types >> - TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs >> - TLS Certificate Compression Algorithm IDs >> >> Most of the entries for registrations in these tables have come from >> documents that were NOT adopted by the TLS WG. Sometimes other WG drafts, >> sometimes (mainly ALPN) just using the IANA form. >> _______________________________________________ >> TLS mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
