[TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Alicja Kario <[e-mail]>]

On Monday, 20 October 2025 17:10:01 CEST, Simon Josefsson wrote:
> Eric Rescorla <[e-mail]> writes:
>
>>> *EKR wrote:*>It's purely about whether we think it's 
>>> reasonable to implement.
>>> 
>>> This is the current meaning. RFC8447bis will change the meaning to:
>>> 
>>> “This only means that the associated mechanism is fit for the
>>> purpose for which it was defined.”
>> 
>> Right. Is it not the opinion of the TLS WG that P256/P-384 + MLKEM are fit
>> for that purpose?
>
> RFC8447bis requires IETF-consensus.  I don't think that question has
> been asked IETF-wide at all so far, has it?  Has there been any
> consensus call in the TLS WG on that question even?  So we don't really
> know.
>
>> If not, on what basis, given that we require you to implement P-256 alone?
>
> I don't think this comparison with historic MTI of P-256 alone is
> relevant for deciding about P256+MLDSA today.
>
> It is reasonable that we required you to implement something a couple of
> years ago that we wouldn't require you to implement today, but we
> haven't gotten around to publishing an updated document.
>
> Compare the migration away from MD4, MD5, DSA, DES, RC4.  The tendency
> to move beyond those algorithms happened long time before we got around
> to drop them from recommended/MTI status.
>
> By that line of reasoning, it would make sense to standardize and make
> MTI the brainpoolP256 curve too.  I don't think that is reasonable
> today, so I think the analogy is invalid as an argument.

But goals are different, the purpose of using hybrids is to use well
vetted algorithms and implementations for the classical part. If that
classical part was good enough to be MTI and stay as Recommended now,
it should be good enough to be part of the hybrids too.
-- 
Regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic