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

[John Mattsson <[e-mail]>]

Eric Rescorla wrote:
> What's *not* compliant is if you have an implementation which doesn't
> support P-256, no matter what other groups it supports.


As I wrote in my response to Bernstein, RFC 8446 mandates ECC only when no application profile specifies otherwise. An application profile that removes ECC is compliant with RFC 8446.


Muhammad Usama Sardar wrote:
>couple of sentences that basically tell me nothing about why this draft even exists.
>Specifically, I would like to know more about those users to be able to reach out to them to ask whether they also want attestation.


I agree that the draft should include a more detailed motivation. Some relevant points:


- ML-KEM-512 is likely the most suitable PQC option for some constrained IoT deployments. It is reasonable to expect that several constrained systems will eventually use (D)TLS 1.3 with PQC algorithms.


- ML-KEM-512 is the only adopted quantum-resistant algorithm that can be used to bypass legacy middle boxes. I would like to minimize the use of standalone ECC and ultimately disable it via an application profile.


- In a decade, when standalone ECC is deprecated and considered to offer no meaningful security, some systems may want to migrate to standalone ML-KEM-768 to save energy. However, contrary to some claims, many deployments will not need this second transition. For some systems, the engineering effort to move away from X25519MLKEM768 will not be justified.


- Several countries are recommending or requiring standalone ML-KEM. They may be worth contacting to determine whether they are also interested in attestation.


https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-02.html
https://www.ncsc.gov.uk/whitepaper/next-steps-preparing-for-post-quantum-cryptography
https://www.cyber.gc.ca/en/guidance/cryptographic-algorithms-unclassified-protected-protected-b-information-itsp40111
https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/ism/cybersecurity-guidelines/guidelines-for-cryptography


As noted above, I view ML-KEM-512 as the most useful algorithm in the draft. For middlebox traversal, I would have preferred X25519MLKEM512, but the TLS WG chose not to pursue that option. Long-term, standalone ML-KEM-768 may be a reasonable migration path for some deployments using X25519MLKEM768. Cost savings are measured in absolute dollars, not percentages and Kleinvieh macht auch Mist.


(That said, my support of publication is still conditioned on that the text in Section 5.1 is completely rewritten or removed)


Cheers,
John




On 2025-11-27, 08:59, "Muhammad Usama Sardar" <[e-mail]> wrote:

On 27.11.25 01:16, Eric Rescorla wrote:


> First, the requirement is not that implementations *use* P-256 but
> rather that they implement it.
>
> What's *not* compliant is if you have an implementation which doesn't
> support P-256, no matter what other groups it supports.


Thank you for very precise explanations and clear examples. I fully
agree that the statement I proposed is not required.


-Usama