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

[Deirdre Connolly <[e-mail]>]

>  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

Is this in reference to the Motivations section? That can definitely be
trimmed but was iterated on multiple times because of complaints that the
motivation were 'not sufficient' etc

On Wed, Feb 25, 2026, 12:51 AM Viktor Dukhovni <[e-mail]>
wrote:

> 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.  🇺🇦 Слава Україні!
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>