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".
I am actually not sure, but it would be a very simple solution - and IMHO not
worse
than any documentation option. But IMHO actually better than any other
individual document written up by someone and posted somewhere on the Internet.
So, if there is no IANA/registry reason against this option, it wold be good
to mention it if this doc would go ahead.
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.
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. So i certainly don't think those documents have sufficient doc...
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]
