[TLS] Re: Fwd: New Version Notification for draft-barnes-tls-this-could-have-been-an-email-00.txt

[Viktor Dukhovni <[e-mail]>]

On Tue, Feb 24, 2026 at 07:02:45PM -0800, Eric Rescorla wrote:

> > Nevertheless, the ISE published RFC8998.  If for some reason, we
> > collectively decide that non-hybrid MLKEM is so unpalatable that
> > even standards-track + Recommended=N is unacceptable, then I see
> > no reason why the ISE route would not be an option.
> >
> 
> Standards track is not on the table. This document is up for Informational.

Well, in that case from a "consumer" perspective, there's no disadvatage
in an ISE RFC.  It is then only the "producers" (IETF or ISE) that
have to face the difference.  Ceding the document to the ISE means:

    - The IETF does not need to spend time debating its content.
    - The IETF has less say about its content.

Two sides of the same coin.  Which is more important?  Influencing how
the algorithm is presented to its consumers, or disclaiming all
responsibility for how and whether it is consumed?

The practical impact is of either choice is marginal, but if one truly
believes that caveats are important and the codepoints should only be
used by those duly cautioned, then perhaps the IETF route has value,
if even if agreeing on the requisite language may be hard.

My take is that if the authors trim the document's attempt at soft
advocacy for use of non-hybrid ML-KEM, and just specify it clearly, and
also reflect the various community concerns in the security
conciderations, then the specification can be published as a sound basis
for interoperability, without the appearance that the IETF *endorsing*
choosing non-hybrid key agreement at this point in time.

-- 
    Viktor.  🇺🇦 Слава Україні!