> https://www.netmeister.org/blog/pqc-use-2025-09.html
Thanks for the pointer and summary; but let me emphasize that the
changes since March don't answer my question.
To repeat: "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."
These were already in the draft in March. It's circular for Amazon to
(1) subsequently implement them on servers and (2) retroactively argue
that this justifies them. Why are they in the draft in the first place?
As a reminder: "IETF participants use their best engineering judgment to
find the best solution for the whole Internet, not just the best
solution for any particular network, technology, vendor, or user."
The TLS WG charter sets goals of improving "security, privacy, and
deployability". The one option in the draft that's actually in wide use
is the obvious choice for deployability _and_ the option that avoids
unnecessary security risks.
I'm not saying that it's impossible to argue for other options. For
example, I've laid out a case for higher security margins on the
post-quantum side, meaning X25519MLKEM1024, and I've explained how it's
possible to make a case for higher security margins also on the
pre-quantum side, meaning X448MLKEM1024. But I simply don't understand
the motivation for SecP256r1MLKEM768 and SecP384r1MLKEM1024. I saw the
brief claims regarding compliance requirements, but those claims seem to
be mixing up SecP256r1MLKEM768 and SecP384r1MLKEM1024 (which as far as I
know aren't required for anything) with standalone P-256 and P-384
(which _are_ sometimes mandated, unfortunately).
---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]
