On Fri, Apr 3, 2026 at 11:53 AM David Benjamin <[email protected]> wrote:
> 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. > I don't believe I'm saying this feedback isn't valid. I'm saying that "you should publish this so that the IEEE can use it" doesn't seem like a very convincing argument if you think people shouldn't use it. > - 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. > This seems to me to be a set of distinct questions from this liaison statement. It seems to me that there are at least three main cases here: 1. Algorithms which the IETF is working on and is going to recommend and/or has recommended (Recommended=Y) 2. Algorithms which the IETF is working on but is not going to recommend. 3. Algorithms which the IETF is not working on Case (1) requires an RFC publication and therefore I think we can ignore this one for this discussion. Case (3) will not be published as an RFC and so people who want to implement them just need to rely on the I-D or whatever other document was provided to the experts, and the code point reflects that document. This leaves us with Case (2). I agree that it's useful for third parties to be able to distinguish whether a given notional algorithm is "finished" in the sense that the IETF might publish an updated version of that algorithm, potentially with a different code point. That normally happens with RFC publication, but we find ourselves in the difficult case where an algorithm *is* being worked on in the IETF but there is real contention about whether it should be published [0], leaving us in an unfortunate situation. This case should be rare, however, because algorithms which are adopted are typically published, and I don't think it's particularly hard to distinguish from cases like draft-10 of some future version of TLS. If this document is published as an IETF RFC, then the problem will go away. If not, then there will be a number of choices: - The ISE can publish the document as an RFC (assuming the ISE is willing.) - The external SDO can publish their own document specifying the algorithm, potentially using some content form this one [1]. - The external SDO can hold their nose and cite the I-D. Of course these are also the exact same choices said SDO would have if the IETF had never taken up the document in the first place. -Ekr [0] I agree with you that the level of contention here is out of proportion to the stakes of how much it matters whether the RFC is published. [1] Note that we do this ourselves sometimes for other reasons.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
