On Fri, Apr 3, 2026 at 11:26 AM Russ Housley <[email protected]> wrote:
> 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]> 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. > I don't believe that that's actually true. Here are the criteria: Criteria that SHOULD be applied by the designated experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or useful only for a single application, and whether the registration description is clear. This is somewhat less than interoperability, ISTM. 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, > Perhaps. Consider the following hypothetical. Suppose that there was a draft that specified a ROT13-based AEAD, that it clearly captures the details in an interoperable manner, and that for some reason some other SDOs wanted to publish documents that relied on that. Do you think the IETF should publish that document? > 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. > I don't think that means that we need to publish every algorithm someone wants to use. > and other SDOs and many organizations that want to purchase > implementations cannot use I-Ds for thir purposes. > As Richard Barnes indicated, that seems to me like their problem, not ours. They could simply cite the I-D by number. It's not like there's some law forbidding them from doing so, and as draft-carpenter-gendispatch-anachronisms, we routinely cite I-Ds ourselves. [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. > All RFCs in the IETF Stream now say that, as a result of RFC 8789. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
