> 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]> 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] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
