Eric: > On Apr 3, 2026, at 2:00 PM, Eric Rescorla <[email protected]> wrote: > > On Fri, Apr 3, 2026 at 5:17 AM Russ Housley <[email protected] > <mailto:[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!
Of course, I recognize that is point we are discussion, and hopefully the discussion will lead to a consensus. I think that we agree that and Internet-Draft has become sufficient for an IANA code point assignment for a cipher suite. This situation requires the IANA Designated Expert to review the document to make sure it accurately captures the details for using the algorithm in an interoperable manner. If the IETF does not publish such document in a way that other SDOs can cite them, then some other group will fill that void. We know that the IEEE needs a document to reference. I believe 3GPP and ITU-T are in the same situation. In my view, another body filling that void would be bad for the IETF. Maybe that is the point where we disagree, >>> 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. Agreed. I think that we both want crypto algorithm agility in TLS implementations. Yet, the I-D is a work in progress, and other SDOs and many organizations that want to purchase implementations cannot use I-Ds for thir purposes. > [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." Not all RFCs say that. For example, the Independent Submission Stream do not. However, in my view, it would be a poor outcome for algorithm documents that fail to gain TLS WG consensus to become Independent Submission Stream documents. Down the road, if the TLS WG becomes comfortable with the algorithm, there would need to be a lot more work to change streams and mark the IANA registry as Recommended=Y. Russ
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
