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

[John Mattsson <[e-mail]>]

If TLS intends to use hybrids long-term, a very conservative option would be ML-KEM+HQC-KEM. The ECC component of today’s PQ/T hybrids like X25519MLKEM768 will not provide any security once/if CRCQs become practical. ML-KEM+HQC-KEM offers significantly better performance than Classic McEliece and FrodoKEM for ephemeral key exchange, relies on two fundamentally different cryptographic assumptions (lattice and code).

Whether unstructured FrodoKEM or the two structured schemes in ML-KEM + HQC-KEM are more likely to face future theoretical cryptanalysis is debatable, but I believe ML-KEM+HQC-KEM is less likely to suffer from fatal implementation issues.

https://csrc.nist.gov/csrc/media/Events/2025/workshop-on-guidance-for-kems/documents/papers/ml-kem-is-great-paper.pdf
https://csrc.nist.gov/csrc/media/Presentations/2025/ml-kem-is-great/images-media/ml-kem-is-great.pdf

Cheers,
John Preuß Mattsson

From: John Mattsson <john.mattsson=[e-mail]>
Date: Tuesday, 25 November 2025 at 14:21
To: Simon Josefsson <simon=[e-mail]>, Eric Rescorla <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

Simon Josefsson wrote:
>non-NIST/MLKEM hybrid PQ KEM for TLS. FrodoKEM? Streamlined NTRU Prime? We need more hybrid PQ options.

This makes absolutely no sense. Is Kyber (mostly developed by European cryptographers) suddenly bad just because NIST think it is good? Would you stop using NTRU Prime if it was standardized by NIST?

Adding more structured lattice-based cryptography such as NTRU Prime does not add much value. Agree that registering TLS code-points for FrodoKEM from a non-paywalled specification should be done.

>BSI recommends FrodoKEM and Classic McEliece, presumably leading to that high-value
attack targets in Germany uses them.  To me, those count as strong examples of external vetting.

Is ANSSI writing that Classic McEliece is not recommended also a strong example of external vetting?

>I think it may be that is actually EASIER to add another algorithm with similar characteristics as MLKEM, such as Streamlined NTRU Prime or FrodoKEM, because implementers will already have resolved those similar concerns (buffer sizes, protocol limits, API concerns etc).

FrodoKEM does not have similar characteristics to ML-KEM at all. ML-KEM have one order of magnitude smaller public keys/encapsulations and two orders of magnitude better performance.

I think HQC-KEM is the only reasonable algorithm for TLS WG to add as a backup to ML-KEM. It is code-based and has performance properties so that it could be used widely instead of ML-KEM.

Cheers,
John


From: Simon Josefsson <simon=[e-mail]>
Date: Monday, 24 November 2025 at 20:05
To: Eric Rescorla <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

Eric Rescorla <[e-mail]> writes:

> On Mon, Nov 24, 2025 at 7:14 AM Simon Josefsson <simon=
> [e-mail]> wrote:
>
>> We are having trouble getting safe hybrid PQ solutions published.  Until
>> we have a couple of widely deployed hybrid PQ KEMs published,
>> implemented and deployed, I don't think we should fragment the already
>> thin resources we have to reach that goal by spending further cycles on,
>> and then publish a fragile solutions like this.  Please prioritize a
>> non-NIST/MLKEM hybrid PQ KEM for TLS.  FrodoKEM?  Streamlined NTRU
>> Prime?  We need more hybrid PQ options.
>>
>
> Why? The general deployed pattern in TLS is to have a small number of
> dominant algorithms and we already have X25519+MLKEM widely deployed.
> Given that any particular connection can only be protected with a single
> algorithm, it's not clear to me how the world is improved by having multiple
> algorithms with roughly the same performance properties.

Historically, I believe we have been helped by having multiple security
options available to jump between when new security problems are
published.  We don't know the nature of future security problems,
therefor hedging by having a couple of alternatives readily available
may help.  There is a cost to that, but I think it is small price
compared to the risks involved.

> I could see some argument for having some algorithm with significantly
> different performance/security tradeoff (though as I understand it there are
> some practical challenges to adding Classic McEliece), but that doesn't
> seem to be what you're suggesting here.

I'm asking for that too, Classic McEliece can be another alternative.
Given that ML-KEM has a PQ KEM monopoly here, I think almost anything we
can add will be an improvement.

I think it may be that is actually EASIER to add another algorithm with
similar characteristics as MLKEM, such as Streamlined NTRU Prime or
FrodoKEM, because implementers will already have resolved those similar
concerns (buffer sizes, protocol limits, API concerns etc).  That's why
I picked those two.  I would like to have Classic McEliece too, because
for some non-web TLS applications, it offers better properties than the
others.  From a security hedging point of view, I agree adding something
widely different make more sense (like Classic McEliece), but I don't
see these as an either-or situation.

> More generally I am opposed to the IETF publishing any algorithm
> specification
> for TLS which has not been externally vetted. That could mean standardized
> elsewhere or sign-off by CFRG, but the TLS WG should not just be picking
> up algorithms without external review and adding them to TLS.

What do you mean by 'externally vetted'?  Who to judge the quality of
the external vetter?  OpenSSH uses Streamlined NTRU Prime for many
years, and SSH traffic is a high-value attack target.  BSI recommends
FrodoKEM and Classic McEliece, presumably leading to that high-value
attack targets in Germany uses them.  To me, those count as strong
examples of external vetting.

What I often see is a request like yours is pretty much the same as
saying that nobody except NIST have the resources to evaluate crypto
algorithms, and that we should trust them.  I think that is as unwise as
only trusting BSI or OpenSSH.

/Simon