Thanks, Ekr, a) draft as documentation:
admittedly i hadn't checked 8447 because i felt that i was remembering in some old days (still this millenium though) when i thought the official IETF wisdom was that drafts didn't exist after their expiry date and the ongoing availability on some IETF URL was just for the benefit of historians but that they should never be considered as actually still alive documents or "current" references. So either i was mis-remembering that, or i would have expected some generic process RFC to have changed that situation. But of course the fact that 8447 got through IESG review with such a statement does prove that at least for the purpose we're interested here, drafts are permanent documentsand certainly a lot easier than ISE RFCs. > 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. I think that very much depends on what scope of responsibility and expertise TLS does have or wants to claim it has. Richards drafts makes some claims re. for example the crypto expertise, or lack thereof. Not sure if he is right. There also does not seem to be a well established process of making WGs do reviews of other WGs work on "order" of IESG. That instrument rather seems to be directorates if i am not mistaken. And of course there are registry experts... c) Sorry for the incorrect language of calling crypto mechanism "codec". Cheers Toerless On Tue, Feb 24, 2026 at 12:29:56PM -0800, Eric Rescorla wrote: > 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] > > -- --- [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
