Re: [TLS] ML-KEM key agreement for TLS 1.3

True, Classic McEliece is not possible with the current length restrictions. FrodoKEM does not seem to get any open-access standard. Cryptographic algorithm standards behind paywalls are a cybersecurity risk. I have seen several implementations that claim to follow a paywalled standard but in reality seem to have been implemented from Wikipidia and skip essential security considerations and requirements. If any European country want to use FrodoKEM, they should drive FrodoKEM in CFRG, or publish the specification themselves. An alternative conservative solution would be to combine ML-KEM with HQC/BIKE and x25519.

Secret and propriatary security protocols are much much worse. Rob Sayre mentioned iMessage in an earlier post. I think Apple is the worst offender of deploying secret and propriatary protocols to billions of users. The distance between their privacy marketing (privacy is a human right) and what is delivered by the secret iMessage are AirDrop protocols is astonishing to say the least.
https://www.rollingstone.com/politics/politics-features/whatsapp-imessage-facebook-apple-fbi-privacy-1261816/
https://arstechnica.com/security/2024/01/hackers-can-id-unique-apple-airdrop-users-chinese-authorities-claim-to-do-just-that/

Cheers,
John Preuß Mattsson

From: TLS <tls-bounces@ietf.org> on behalf of Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Wednesday, 6 March 2024 at 17:46
To: TLS@ietf.org <tls@ietf.org>
Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3
On Wed, Mar 06, 2024 at 04:25:16PM +0000, John Mattsson wrote:
> I think TLS should register all algorithm variants standardized by
> NIST. That means ML-KEM-512, ML-KEM-768, and ML-KEM-1024. And in
> the future a subset of HQC/BIKE/Classic McEliece.

Just as note, supporting Classic McEliece is not possible at all due to
the key size exceeding hard TLS 1.3 limit.

Even FrodoKEM, which seems to be quite widely viewed as "next step up"
from likes of ML-KEM, has painfully large keys. But at least those do
not bust any hard limits.

-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls