[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

[John Mattsson <[e-mail]>]

Hi

I received an offline comment from a senior IETF participant suggesting that I had misunderstood the draft and that the key reuse in question referred to reuse within a single session. That is not accurate. The draft talks about static keys, i.e., keys used in more than one key-establishment.

Given the apparent confusion between 1. reuse of ephemeral keys within a session, 2. reuse of ephemeral keys across sessions, and 3. static keys, each of which carries distinct privacy and security implications, I recommend that the AD ensure that all not yet published drafts use very precise terminology. Specifically, a key used in more than one key-establishment should use the well-established term “static key”.

---

1. Reuse of ephemeral keys within a session:

- Session A: ClientHello with MLKEM768 KeyShareEntry1 and X25519MLKEM768 KeyShareEntry2 both containing the same ML-KEM public key.

2. Reuse of ephemeral keys across sessions:

- Session B1. ClientHello with MLKEM768 KeyShareEntry3 and X25519 KeyShareEntry4. Sever picks X25519 KeyShareEntry4.

- Session B2. ClientHello with MLKEM768 KeyShareEntry3 and X25519 KeyShareEntry5.

3. Static keys

- Session C1. ClientHello with MLKEM768 KeyShareEntry6. Sever picks MLKEM768 KeyShareEntry6

- Session C2. ClientHello with MLKEM768 KeyShareEntry6. Sever picks MLKEM768 KeyShareEntry6

---

Issues with the text on static keys were clearly raised during the first WGLC and should have been addressed before the second. Having to repeat the same issues is both frustrating and a waste of time.

The major issues, that the draft lacks proper security considerations for the use of static keys (they should be quite negative), and that it does not explain how an implementation using static keys can be conformant with NIST specifications, were raised during the first WGLC and have not been addressed. During the second WGLC, it was identified that conformance is intrinsically linked to the patent license.

My constructive suggestion is to remove all text regarding static keys, as there is no reason for this draft to include them. I do not believe comparisons with draft-ietf-tls-hybrid-design are relevant, since that document serves a completely different purpose and does not register code points.

If the draft intends to retain any text on static keys, NIST SP 1800-37, Addressing Visibility Challenges with TLS 1.3 within the Enterprise, is a useful reference regarding the negative privacy and security implications of static keys. I do not have specific guidance on how to achieve conformance with NIST specifications when using static keys, but that issue must clearly be resolved.

I do not find any text in RFC 8446 that allows the use of static keys. If the TLS WG intends to explicitly permit static keys again, their use should be explicitly negotiated, as done in TLS 1.2 or draft-rhrd-tls-tls13-visibility.

As I have seen no response from the authors indicating that they plan to address this issue, I am opposed to publishing this document.

Cheers,
John

From: Russ Housley <[e-mail]>
Date: Thursday, 12 February 2026 at 22:38
To: Joseph Salowey <[e-mail]>
Cc:
<[e-mail]>, John Mattsson <[e-mail]>
Subject: Re: [TLS] WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

I support the publication of this document as an RFC.  I would prefer to have the clarity about ephemeral vs. static ML-KEM keys as posted by John Mattsson, but I can live with it as-is.

Russ


On Feb 12, 2026, at 3:08 PM, John Mattsson <john.mattsson=[e-mail]> wrote:

Hi,

I support publication iff all text related to “key reuse” is removed. In its current form, I do not believe -07 should be published.

Major Comments:

- FIPS 203 states that:

“the licensed patents be freely available to be practiced by any implementer of the ML-KEM algorithm as published by NIST.”

“requirements for the secure use of KEMs in applications, see SP 800-227.”

A reused key is, by definition, a static key. SP 800-227 imposes additional requirements for static keys compared to ephemeral keys. The draft does not explain how an implementer can satisfy these requirements. This creates potential non-conformance with NIST specifications.

-  The draft does not describe the significant security and privacy problems associated with key reuse. IND-CCA is a theoretical property of the algorithm. However, the security and privacy problems are related to the reuse of keys in the TLS 1.3 protocol in deployments.

Minor Comments:

- The discussion of randomness reuse in ciphertexts and references to SP 800-227 do not belong in a “key reuse” section. Ciphertexts are not keys, and SP 800-227 contains broader guidelines and requirements beyond static keys.

- “The client's shares are listed in descending order of client preference; the server selects one algorithm and sends its corresponding share.”

The server may also select no share and respond with a handshake_failure or a HelloRetryRequest (HRR). Since this is already specified in RFC 8446, it would be better to remove this text and simply reference RFC 8446.

- Section 5.1 appears to ​mix different concepts: hybrids, PQ/T hybrids, and lattice-based PQ/T hybrids. I assume the person asking for this section wanted a comparison with [ECDHE-MLKEM]. I suggest doing that. In the future, PQ/T hybrids will likely become less common, but it is unclear whether other hybrids (e.g., ML-KEM + HQC-KEM) will gain adoption.

Cheers,
John

From: Joseph Salowey <[e-mail]>
Date: Thursday, 12 February 2026 at 20:06
To:
<[e-mail]>
Subject: [TLS] WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

This message starts the second Working Group Last Call for the pure ML-KEM document (draft-ietf-tls-mlkem-07).

The file can be retrieved from:
https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

The diff with the previous WGLC draft (-05) is here:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html<https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-06&difftype=--html>

The main focus of this WGLC is to review new text providing more context around the use of pure ML-KEM.  For those who indicated they wanted this text, please let us know if the new text satisfies you and if you support publication. This working group last call will end on February 27, 2026.

Thank You.
_______________________________________________
TLS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]