On Tue, Feb 24, 2026 at 12:23 PM Toerless Eckert <[email protected]> wrote:
> I think it's a +1 if i recommend to not explicitly mention the ISE track > option, > because the ISE is really VERY independent, and i don't think that the > random > crypto algo/use-case would suit the ISE track. So it's NOT a generic > fallback > option IMHO that we should enlist in the doc if it should go forward. > > However, i wonder if there is any rule against using an individual draft > (that will > never become RFC) to be a sufficient reference for IANA "documentation > required". > This is how it already works. See: https://www.rfc-editor.org/rfc/rfc8447.html Note: The role of the designated expert is described in RFC 8447 <https://www.rfc-editor.org/rfc/rfc8447>. The designated expert [RFC8126 <https://www.rfc-editor.org/rfc/rfc8126>] ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the supported group. Likewise, if this doc would go ahead, i think it would be useful to mention > that > by now there should be no reason why other WGs or RGs should not be > allowed to > publish RFCs with such a crypto algorithm/code-point. For example CFRG > could do > this, or for example something like IOTOPS or MOPS or any othre group that > isworking off some specific (industry) use-case that may already have some > crypto they "need" to use. One can of course argue if other groups beside > TLS > should be allowed to produce recommended=Y, but recommended=N should > certainly > be allowed. > As noted above, anyone can register, though if I were the IESG I would refuse to publish any TLS code point that hadn't gone through some review by the TLS WG. Practically speaking i would foremost wonder about e.g.: the military, which > typically loves to use their own crypto ("obfuscation always works" (TM)), > and if a documentation would suffice that simply then states the clearance > level > you need to access the document. So far i only see a bunch of "Reserved" > entries by Pasi Eronen, which could or could not be placeholders for such > secret codecs. I'm not sure what you mean by "codecs" as TLS doesn't have codecs. I don't recall the reason for the block of cipher suites Pasi reserved, but given where it is, I expect it was just ordinary code point squatting. -Ekr > > Cheers > Toerless > > On Tue, Feb 24, 2026 at 10:27:43AM +0000, Stephen Farrell wrote: > > > > Hiya, > > > > On 24/02/2026 09:15, Bellebaum, Thomas wrote: > > > Hi Nadim, > > > > > > > > 1. Make ECHDE/MLKEM Recommended=Y (as also suggested by Bas's > draft). > > > > > 2. Decline to publish draft-ietf-tls-mlkem > > > > > > > > This is the best case scenario outcome for TLS’s security and > benefit to humanity in my view and I strongly support it. > > > > > > I agree. The medium-term (i.e. after WGLC) question regarding 2. would > be whether that draft > > > > > > a) should be sent to the ISE for publication elsewhere (which in case > of no conflicts any author may do without WG approval), or > > > > Note that the above phrasing could be misleading - authors *ask* the ISE > > for publication, and the ISE can also decline to publish, for basically > > whatever reason the ISE decides. (The "I" does mean independent:-) The > > ISE can also decide to only publish if some ISE-chosen caveats are added > > to a document. Or the ISE might conclude that the fact that the WG has > > decided to not publish such RFCs means that it'd be too close to a > > conflict with the IETF stream for the ISE to publish 'em instead. > > > > The point is that if Richard's plan were adopted, one can't assume that > > TLS codepoint RFCs, not adopted by the WG, would instead be emitted by > > the ISE. > > > > Cheers, > > S. > > > > PS: I'm not arguing for or against Richard's plan in the above. > > > > > b) should be held at the WG for eventual reevaluation/publication in a > few years. > > > > > > Personally, I think we have seen enough interest in deploying this > particular PQ-no-seatbelt algorithm to prefer b) and expand the > considerations in the document in the meantime. > > > > > > -- TBB > > > > > > > > > _______________________________________________ > > > TLS mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > > > > > > > -- > --- > [email protected] > > _______________________________________________ > 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]
