[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

[Muhammad Usama Sardar <[e-mail]>]

On 27.11.25 17:02, John Mattsson wrote:

> Eric Rescorla wrote:
> > What's *not* compliant is if you have an implementation which doesn't
> > support P-256, no matter what other groups it supports.
>
> As I wrote in my response to Bernstein,
Thanks John for writing a separate email. I couldn't follow all these 
lengthy discussions.
> RFC 8446 mandates ECC only when no application profile specifies 
> otherwise.

Looking at starting text of section 9.1, you are right. I guess Ekr's 
implicit assumption for simplicity was that such an "application profile 
standard" does not exist for that specific discussion.

But this raises a new question in my mind: RFC8446bis-14 uses 2x 
"application profile standard" and 2x "application profile" but I don't 
find any definition of that. I am curious who is the /authority/ for 
such "application profile standards". You mention CNSA 1.0, CNSA 2.0 and 
3GPP TLS profile, which make sense to me. But you also mention:

 > Constrained devices, for example, often support only one of secp256r1 
or X25519.

which confuses me. Do we have an exhaustive list of application profile 
standards? If any one can write such profiles, then the whole idea of 
MTI becomes questionable to me. That is, I could write my own profile 
and say I am still compliant with RFC 8446.

> Muhammad Usama Sardar wrote:
> >couple of sentences that basically tell me nothing about why this 
> draft even exists.
> >Specifically, I would like to know more about those users to be able 
> to reach out to them to ask whether they also want attestation.
>
> I agree that the draft should include a more detailed motivation. Some 
> relevant points: [...]
I am in no position to judge your points. But I really hope the WG can 
agree on at least some of that to be added in motivation.
> - Several countries are recommending or requiring standalone ML-KEM. 
> They may be worth contacting to determine whether they are also 
> interested in attestation.

Thanks very much for the links.

I will appreciate if at least one of those which explicitly mentions 
MLKEM was added in motivation section of the draft.

> (That said, my support of publication is still conditioned on that the 
> text in Section 5.1 is completely rewritten or removed)

Is it this one? [0] I have no opinion from PQ perspective but from 
traditional crypto perspective, I agree with your concern on key reuse. 
Intuitively, I would assume the same problems would hold in pure PQ but 
there may be subtleties.

-Usama

[0] https://mailarchive.ietf.org/arch/msg/tls/Wc0tnrJX0AwMnjBspeM3pxCwEoU/