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

[Eric Rescorla <[e-mail]>]

On Mon, Nov 24, 2025 at 11:04 AM Simon Josefsson <[e-mail]>
wrote:

> 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.
>

Thanks for the explanation. I think this is an understandable perspective,
but given that we're already hedging by using hybrids, I feel comfortable
that if there were to be some severe weakness in one of the components
we could adapt relatively quickly.


> 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).


I agree with this.


> 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'?


I already answered this in the paragraph you're quoting: "standardized
elsewhere
or sign-off by CFRG". I could imagine some other process that would give me
confidence, but I'd have to hear more about said process.




> Who to judge the quality of
> the external vetter?


The IETF, though of course different people may have different opinions.
At present, of course, there is no such rule, so we're just discussing what
is sufficient for each of us to have confidence, which might or might not
entail external vetting at all.



> 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.


That may be what others are saying, but it's not what *I'm* saying,
as should be clear from the text above.

-Ekr