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

[Simon Josefsson <[e-mail]>]

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