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

[John Mattsson <[e-mail]>]

>MTI is imho meaningless (there is no such thing as mandatory to implement, since no enforcement arm of IETF exists, thankfully, so implementers can just not implement something if they don't want to

The MTI flag has an effect in industries that believe in standard compliance. Both TLS and HTTPS are used in many other places than the Web. In the case of TLS, where the specifications are not continuously updated, MTI can have a negative effect on security. There are many TLS 1.2 implementations supporting TLS_RSA_WITH_AES_128_CBC_SHA (Static RSA key exchange, AES-CBC in MtE composition, and SHA-1) just because it is MTI in RFC 5246. 3GPP mandated AEAD and PFS in TLS 1.2 10 years ago, but there are still nodes supporting TLS_RSA_WITH_AES_128_CBC_SHA because of RFC 5246.

That said, I think we should leave MTI and Recommended discussion to later.

From: Sophie Schmieg <[e-mail]>
Date: Monday, 20 October 2025 at 20:31
To: Alicja Kario <hkario=[e-mail]>
Cc: Simon Josefsson <simon=[e-mail]>, [e-mail] <[e-mail]>
Subject: [TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM KeyAgreement for TLSv1.3
Note that this is discussing the key agreement to begin with, so it would be ML-KEM in any case. And again, I have no strong preference on any of the flags, MTI is imho meaningless (there is no such thing as mandatory to implement, since no enforcement arm of IETF exists, thankfully, so implementers can just not implement something if they don't want to), and the RECOMMENDED flag is similarly undefined, as has been argued back and forth on the list. Let's just ship it, please :)

On Mon, Oct 20, 2025 at 10:14 AM Alicja Kario <hkario=[e-mail]<mailto:[e-mail]>> wrote:
On Monday, 20 October 2025 17:57:33 CEST, Simon Josefsson wrote:
> Alicja Kario <hkario=[e-mail]<mailto:[e-mail]>> writes:
>
>> 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.
>
> I disagree with that, if you imply that the P256 hybrid should be MTI.
>
> So if old DSA was still MTI we have to make DSA + ML-DSA MTI too?

We're not discussing if any of the hybrids should be mandatory to
implement.
And what is the purpose of discussing alternative timelines where DSA is
dominant?

> I think we should make decisions about P256+MLDSA based on today's
> knowledge about P256 and MLDSA (and the combiner) rather than having
> necessarily make decisions that use earlier decisions on P256 as a least
> common denominator (i.e., MTI).

And what did fundamentally change since the P-256 was marked as MTI and
both it and secp384r1 curve were marked as Recommended?
--
Regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com<http://www.cz.redhat.com>
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

_______________________________________________
TLS mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


--

Sophie Schmieg | Information Security Engineer | ISE Crypto | [e-mail]<mailto:[e-mail]>