On Fri, Apr 3, 2026, 14:01 Eric Rescorla <[email protected]> wrote: > > > On Fri, Apr 3, 2026 at 5:17 AM Russ Housley <[email protected]> wrote: > >> >> 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. >> > > I am of course aware of this distinction, but I don't think it really > matters much > in this context. While it's true that Recommended=Y is intended to indicate > a judgement by the TLS WG, I think it's clear that many regard the > publication > of an RFC by the TLS WG as a form of endorsement, even when Recommended=N > [0]. > In fact, this is precisely why the publication of some documents has > become so > controversial. > > Taking a step back, it seems to me that the people who are opposed to > publication of this document are of the opinion that people shouldn't > use the algorithms it describes. The argument you are advancing here > is that the IETF should publish this document because it enables others > (in this case IEEE) to use these algorithms, but whether that's a good > thing or not is precisely the point of contention! >
Sure, if one wants to view this debate as "does the TLS WG think this algorithm should be used", then a lack of endorsement impacting IEEE may well be the point. But if that is the point, the TLS WG gets to own that. It is then totally fair for an IEEE liaison, or members of the TLS WG, to say "no, I do think they should be used sometimes, please publish it", and the TLS WG gets consider such feedback accordingly, not complain "you are wrong to want an RFC". We don't get to have it both ways: - If the TLS WG wants to increase the value of its endorsements by making it harder to use things that it doesn't endorse through publication, then the TLS WG gets to hear feedback when others disagree with a lack of a decision to publish. This is one such feedback and is, under this theory, valid. - If the TLS WG wants to avoid that feedback and discussion by saying "no, you don't need us to publish", that needs to actually be true. Pointing at a I-D does not fully meet the needs because an I-D, even with a codepoint assigned, is still formally a work in progress. The TLS WG itself uses that fact all the time. So when folks need a "finished" thing to cite, it is fair for them to give feedback asking for the TLS WG to publish that. - If the TLS WG wants to solve this by abandon the admonition that I-Ds are a work-in-progress, that will apply to *all* I-Ds. I think this would be an extremely bad outcome. It means we really wouldn't have a leg to stand on when some vendor complains that we cannot fix an issue in TLS 1.4 draft 10 because they shipped it already. - If the TLS WG wants to just leave it to other folks to figure out a "finished" state, well, if that doesn't happen at IETF, as Russ says, someone else will do it outside IETF. That will erode the TLS WG's status as the venue where the TLS community coordinates on what the protocol means, and make things more complicated for folks who now have to juggle venues for coordination. I do not think this subjective risk management question of hybrids is worthy of all of this drama and we should just accept and consider this feedback. (Indeed for me, the main outcome of this debate is that, if I could redo the past several years, I would have shipped pure ML-KEM-768 over X25519MLKEM768 in the parts of TLS I'm involved in.) > 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. >> > > The TLS WG and the IETF have already determined that the I-Ds are an > acceptable > reference for code point definitions. > A definition of a code point is not the same as no longer being a work in progress. The IETF is very clear that I-Ds are works in progress. This is about as unambiguous as one can get: > Internet-Drafts (often referred to simply as "drafts") have no formal status, and are subject to change or removal at any time; therefore they should not be cited or quoted in any formal document. https://www.ietf.org/participate/ids/ The IETF *could* choose to abandon that claim but, like I said, I think that would have negative consequences for work the IETF *does* intend to publish. -Ekr > > [0] I don't think this position is entirely unreasonable given that the > documents > state on the face of them that they "represent[s] the consensus of the > IETF community." >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
