Jan Schaumann writes:
> I don't think I can follow a logic that says
> X25519MLKEM768 should be recommended, but not the
> others (unless one were to imply that standalone P-256
> and P-384 should not be recommended).
For me, the central point is that P-256 and P-384 create neverending
real-world implementation failures, such as CVE-2023-6135 in Firefox.
This is an argument against standalone P-256 and P-384 as well as this
draft's SecP256r1MLKEM768 and SecP384r1MLKEM1024.
For standalone P-256 in particular, the current status---mandated, and
according to some reports still used by 10% of TLS sessions---means that
the deprecation process should be gradual, starting with announcing the
plan, mandating a replacement, tracking deployment trends, etc.
Standalone P-384 is easier to get rid of: it's not needed for getting
data through, and it has far less usage in the first place.
As for SecP256r1MLKEM768 and SecP384r1MLKEM1024 in this draft, the
current status is that they're basically not supported in deployments at
all. The claims that these are needed for compliance don't seem to have
withstood examination. So I'm puzzled as to why they're there.
---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.
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
