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

[Eric Rescorla <[e-mail]>]

On Wed, Nov 26, 2025 at 1:17 PM Muhammad Usama Sardar <
[e-mail]> wrote:

> On 26.11.25 21:44, Eric Rescorla wrote:
>
> Right, though it's important to be clear on what that means:
>
> - You have to support key_share, but you don't necessarily need to send it
> (e.g., if you're doing pure PSK without any DH).
>
> cool, thanks very much. That resolves the apparent mismatch between
> section 9.1 and Figure 1 in my head.
>
> - The requirement for key_share doesn't require you to do ECC, just to
> support the extension generally. You'd be in compliance with this
> particular MUST if you supported pure MLKEM, though of course not with the
> MUST to support P-256.
>
> I think the draft should have a statement somewhere stating that it is no
> longer compliant with the base TLS specs, with pointer to section 9.1 of
> RFC 8446bis.
>
I don't think that's correct. In general any draft which defines a new
algorithm
just allows that algorithm to be used in TLS, but doesn't otherwise affect
TLS.
This is true for this draft but also for the MLKEM-ECC hybrids.

An implementation could choose to implement just the new algorithm and
not the MTI algorithm(s) in the same class, in which case the implementation
would be noncompliant, but it's possible to be noncompliant based purely
on the algorithms registered in RFC 8446, for instance by implementing
just P-384 and not P-256.

-Ekr