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

["D. J. Bernstein" <[e-mail]>]

Kris Kwiatkowski writes:
> At the same time, keeping the number of algorithms
> to a minimum was considered beneficial.

The minimum useful number here would be 1. The draft has 3. Clearly the
draft is also taking other considerations into account.

> What would be the use case for that code point?

An implementor concerned about the security of ML-KEM-768 decides to add
ML-KEM-1024 to reduce risks.

Currently the draft requires P-384 for this use case, but this incurs
the real-world security risks illustrated by, e.g., CVE-2023-6135 in
Firefox (see https://bugzilla.mozilla.org/show_bug.cgi?id=1853908) and
by many further examples of the NSA curves creating unnecessary security
problems (see https://cr.yp.to/papers.html#safecurves)

Regarding the choice between X25519 and X448 here: X25519 does the job
that we're asking hybrids to do, has more software support than X448,
and is an obvious choice for an implementation that has X25519 available
already. However, it's possible that we'll be in the following scenario:

    (1) User data needs to stay secret for 40 years.
    (2) Computer hardware continues to drop in cost for that period.
    (3) Quantum computing doesn't succeed during that period.

Certainly #1 sometimes happens; #2 is plausible; and it's not crazy to
hope for #3. In this scenario, X448 is a safer choice than X25519. The
fast high-assurance X25519 code in s2n-bignum reportedly took just one
person-year to write and verify; X448 shouldn't be noticeably harder.

---D. J. Bernstein


===== NOTICES REGARDING IETF =====

It has come to my attention that IETF LLC believes that anyone filing a
comment, objection, or appeal is engaging in a copyright giveaway by
default, for example allowing IETF LLC to feed that material into AI
systems for manipulation. Specifically, IETF LLC views any such material
as a "Contribution", and believes that WG chairs, IESG, and other IETF
LLC agents are free to modify the material "unless explicitly disallowed
in the notices contained in a Contribution (in the form specified by the
Legend Instructions)". I am hereby explicitly disallowing such
modifications. Regarding "form", my understanding is that "Legend
Instructions" currently refers to the portion of

    https://web.archive.org/web/20250306221446/https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf

saying that the situation that "the Contributor does not wish to allow
modifications nor to allow publication as an RFC" must be expressed in
the following form: "This document may not be modified, and derivative
works of it may not be created, and it may not be published except as an
Internet-Draft". That expression hereby applies to this message.

I'm fine with redistribution of copies of this message. There are no
confidentiality restrictions on this message. The issue here is with
modifications, not with dissemination.

For other people concerned about what IETF LLC is doing: Feel free to
copy these notices into your own messages. If you're preparing text for
an IETF standard, it's legitimate for IETF LLC to insist on being
allowed to modify the text; but if you're just filing comments then
there's no reason for this.