[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

[Bas Westerbaan <[e-mail]>]

On Thu, Jun 25, 2026 at 7:51 AM Martin Thomson <[e-mail]> 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>