To: [email protected]
Subject: Re: WG Last Call: draft-ietf-tls-mlkem-08
I support advancing this document as Informational, subject to the
changes below, with the registrations marked Recommended: N. Under RFC
9847, N records no IETF statement about the suitability of these
groups.
Martin opened a seam in the error handling logic with #25, let's
stitch it up. I agree with the approach but would not merge it as-is,
and I suggest three changes.
First, the client need not repeat the decapsulation-key checks on
every operation when it already has assurance that the key was validly
generated and protected from modification. That is Bas's point. FIPS
203 Section 7.3 says so directly: "checking of the decapsulation key
need not be performed by the decapsulating party, nor with every
execution of ML-KEM.Decaps. Instead, assurance that this check has
been performed can be acquired through other means." SP 800-227
Section 3.2 gives the concrete case: a module that generated the key
with KeyGen and stored it against modification. The ciphertext check,
by contrast, is required on every decapsulation. I would replace:
"Prior to decapsulation, the client MUST perform the decapsulation
input check from Section 7.3 of {{FIPS203}}."
with:
"Prior to decapsulation, the client MUST have assurance that the
decapsulation-key checks from Section 7.3 of {{FIPS203}} have been
satisfied. As permitted by that section, this assurance MAY be
obtained by other means. The ciphertext check from Section 7.3 MUST be
performed on every invocation of ML-KEM.Decaps."
This relaxes only the client's check of its own key, not the server's
Section 7.2 check of the peer's encapsulation key.
Second, #25 maps three different failures to a single internal_error,
but RFC 8446 and FIPS 203 treat them differently: a peer-input
failure, a local error, and implicit rejection. After the input
checks, ML-KEM.Decaps returns a 32-byte shared secret. A ciphertext
that fails the internal re-encryption comparison takes the
implicit-rejection path and returns a replacement secret, and FIPS 203
Section 6.3 keeps that implicit-reject flag secret and forbids
returning it in any form, so it is not a Decaps error. RFC 8446
Section 6.2 reserves internal_error for failures unrelated to the peer
and uses illegal_parameter for a semantically invalid peer value, so a
failed Section 7.2 encapsulation-key check should be
illegal_parameter. I would replace:
"If ML-KEM checks, encapsulation, or decapsulation fail for any other
reason, the connection MUST be aborted with an internal_error alert."
with:
"If the server's encapsulation-key check from Section 7.2 of
{{FIPS203}} fails, the server MUST abort with an illegal_parameter
alert. If an ML-KEM operation returns an explicit error, the
connection MUST be aborted with an internal_error alert. ML-KEM.Decaps
returns a shared secret on every invocation, so its implicit-rejection
path is not an error and produces no alert."
If implicit rejection leaves the peers with different secrets, the
mismatch is caught by ordinary TLS protected-record processing, not by
a distinct decapsulation error.
Third, Section 4.3 states agreement as a certainty, where FIPS 203
states it probabilistically. I would rewrite the sentence rather than
append a qualifier. Replace:
"The fixed-length shared secret output from the ML-KEM Encaps and
Decaps algorithms over the appropriate keypair and ciphertext results
in the same shared secret shared_secret as its peer, which is inserted
into the TLS 1.3 key schedule in place of the (EC)DHE shared secret,
as shown in {{Section 7.1 of RFC8446bis}}."
with:
"For (pk, sk) output by the applicable ML-KEM parameter set's KeyGen
algorithm and (ct, shared_secret) output by Encaps(pk), Decaps(sk, ct)
returns shared_secret with overwhelming probability. Each peer inserts
its resulting shared secret into the TLS 1.3 key schedule in place of
the (EC)DHE shared secret."
Separately, the freshness language needs a DTLS clarification. The
groups are registered DTLS-OK: Y, and Section 4.2 states without
qualification that ML-KEM ciphertexts MUST NOT be reused. The
requirement is fresh randomness on each ML-KEM.Encaps invocation, per
FIPS 203, not uniqueness of the resulting ciphertext, and RFC 9147
requires the retransmitted handshake bytes to stay unchanged. I would
clarify:
"The server MUST invoke ML-KEM.Encaps using fresh randomness for each
distinct TLS or DTLS handshake. Retransmission of an unchanged
handshake message within the same DTLS handshake is not reuse for this
purpose. The original ciphertext MUST be retransmitted, and
ML-KEM.Encaps MUST NOT be invoked again for the retransmission."
Nick
On Thu, Jun 25, 2026 at 8:52 AM Bas Westerbaan
<[email protected]> wrote:
>
>
>
> On Thu, Jun 25, 2026 at 7:51 AM Martin Thomson <[email protected]> wrote:
>>
>> I think that this is good to go, with nits.
>>
>> I opened a few pull requests, a pair of which demonstrate that the fuss over
>> this draft did seem to get in the way of doing the work.
>>
>> The question in https://github.com/tlswg/draft-ietf-tls-mlkem/pull/24 and
>> https://github.com/tlswg/draft-ietf-tls-mlkem/pull/25 is perhaps worth
>> discussing.
>
>
> I think neither are necessary.
>
> The expanded decapsulation key caches the hash of the encapsulation key. The
> decapsulation key check is whether that hash is correct. FIPS 203 only
> requires that check if the key is from an untrusted source. In the case of
> TLS, you generate the key yourself earlier, so you know the hash is correct.
>
>
>
>>
>> The draft currently asks the client to run a FIPS validation check, but the
>> server only checks the length of the encapsulation key. That asymmetry
>> seemed wrong to me.
>>
>> I think that the right plan (#25) is to limit checking at the TLS layer
>> (which will be visible through the type of alert) to length only. However,
>> I also opened #24, which includes the FIPS checks at the TLS layer. The
>> reason I think that is less desirable is that, were I to implement this, I
>> would want to pass an opaque byte string to the cryptographic code, which
>> would not report on why it failed. Whereas #24 requires that you have a
>> separate validation API. That validation is easy enough, but not something
>> you want in your TLS code, as there are hash function invocations on the
>> client and modulus checks on the server.
>>
>> There is another option, which is to remove all checks (and any requirement
>> to use `illegal_parameter`) from the spec, but that is not consistent with
>> other TLS usage, which generally checks size. I didn't write that option up.
>>
>> On Thu, Jun 25, 2026, at 01:00, Joseph Salowey via Datatracker wrote:
>> > This message initiates a new Working Group Last Call for
>> > draft-ietf-tls-mlkem[1], which defines standalone ML-KEM key
>> > establishment for TLS 1.3. The main question before the working group
>> > is: "Should the working group publish a document specifying stand alone
>> > ML-KEM?". If there is rough consensus then we will push to refine and
>> > publish the document; otherwise, we will stop discussing the draft and
>> > not progress it. Please respond to this call indicating whether you
>> > support publishing a document specifying a stand alone ML-KEM. Please
>> > refrain from further discussion on this topic as most arguments have
>> > been discussed multiple times.
>> >
>> > Why are we holding this consensus call now?
>> >
>> > Significant developments have occurred both within this document and in
>> > the broader TLS ecosystem to address the concerns raised in the last
>> > WGLC. Therefore, the third consensus call is warranted. We ask the
>> > working group to consider document publication in light of these recent
>> > changes:
>> >
>> > - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a
>> > separate consensus call, the WG agreed to promote the X25519MLKEM768
>> > hybrid group to Recommended: Y in the IANA registry. Consequently, the
>> > IANA registry will reflect a clear community preference for a hybrid
>> > because Recommended: Y clearly indicates this while the standalone
>> > ML-KEM groups defined in this draft remain Recommended: N. The updated
>> > security considerations in [1] reference the IANA registry to emphasize
>> > this preference.
>> >
>> > - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG
>> > recently reached consensus to explicitly prohibit key share reuse
>> > across connections in TLS 1.3. The new text changes the guidance from
>> > SHOULD NOT to a strict MUST NOT. This resolves the concerns regarding
>> > static key reuse and its associated privacy and forward-secrecy risks
>> > for ML-KEM.
>> >
>> > - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and
>> > hybrid KEM groups in TLS 1.3. This supports other results which show
>> > that KEMs are secure when used in TLS 1.3 and that hybrid groups are
>> > secure even if one of the components is compromised.
>> >
>> > - Liaisons: We received liaison statements from multiple SDOs including
>> > O-RAN[2], IEEE 802.11[4] and from 3GPP[3] expressing support for the
>> > publication of draft-ietf-tls-mlkem as an RFC as they rely on the IETF
>> > to provide a stable normative reference.
>> >
>> > Please note that a third-party IPR disclosure exists [5] against this
>> > document regarding patents related to the underlying ML-KEM algorithm.
>> > This IPR declaration has not changed since the last WGLC. As a
>> > reminder, per BCP 79, the IETF takes no stance on the validity of
>> > patent claims, and the working group may decide to proceed with a
>> > technology despite IPR disclosures if it decides that such use is
>> > warranted.
>> >
>> > Conduct Reminder: Given the heated nature of previous discussions on
>> > this topic, participants are strongly reminded to adhere to the IETF
>> > Code of Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keep
>> > feedback professional, technical, and focused on the document's text.
>> >
>> > This working group last call will end on 2026-07-08.
>> >
>> > Joe and Sean
>> >
>> > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
>> > [2] https://datatracker.ietf.org/liaison/2198/
>> > [3] https://datatracker.ietf.org/liaison/2151/
>> > [4] https://datatracker.ietf.org/liaison/2148/
>> > [5]
>> > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem
>> >
>> > _______________________________________________
>> > TLS mailing list -- [email protected]
>> > To unsubscribe send an email to [email protected]
>>
>> _______________________________________________
>> TLS mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
