Please reject. Due to it missing some information for Security
Considerations, IMHO this MUST NOT be published as an RFC.
The TLS WG should IMHO ask the groups from the linked liaison statements
and the editors of CNSA2.0 to adopt X25519MLKEM768 instead.
---
Missing information for Security or IANA Considerations:
I think we should have learned from history of TLS and other protocols
that having multiple possible algorithms is a security problem. The same
is true of having multiple choices for the negotiation options in a
protocol. So for each options existence the full and exact arguments
chosen for a spec must be easy to look up.
There is no argument given in this draft for why this new option to TLS
Supported Groups should be added when X25519MLKEM768 is already widely
deployed. It does not even mention why it should be the chosen one if it
were the only cypher or the first post quantum one. I do understand this
was discussed, but it needs to be in the RFC. (It was also not included
in the text of the last call or its linked documents.)
It needs to be written which considerations apply for common expected
negotiation offers.
It needs to be written which will be the most common negotiation offers,
expected based on guessed vendor choices and market forces. And maybe
some relevant but less common ones if the argument is that this is
needed for less common ones. And how these negotiations will interact.
---
Relation with other specs:
There is no argument given for why the linked liaison statements are
requesting this.
There were multiple mentions elsewhere that ultimately imply that
CNSA2.0 requires a non-hybrid ml-kem. By my reading of
CSA_CNSA_2.0_ALGORITHMS.PDF that is wrong, it mentions explicitly
"hybrid solutions may be allowed". draft-becker-cnsa2-tls-profile-04 is
still a draft and does not mention the word hybrid or 25519, so seems to
give no reasoning. The file CSI_CNSA_2.0_FAQ_.PDF goes into more detail
on its preferences regarding hybrids including some written out
arguments. My understand is that those arguments imply to favor
selecting X25519MLKEM768 for CNSA2.0.
The argument that this should be published as RFC for harm reduction
reasons doesn't sound correct to me, but again I could not inspect the
full argument as it was not written out where I read that.
---
I could not find statements from the WG regarding which arguments
regarding previous last calls it considered and what the official
response was. It would be useful if the last call message would include
or link to a summary of all the arguments made after the previous last
call and their official response. That might have made me not send this
message or at least made it much shorter.
Perhaps it is the position of the TLS WG that the text in this last call
after "recent changes:" is supposed to be that. But after reading it and
the one for last call of draft-ietf-tls-mlkem-05, I'm under the
impression that significant arguments where made regarding this draft
before this last call, that were not mentioned. So clarification on that
would be appreciated.
---
Some background how common implementation usage looked before
X25519MLKEM768:
Most Linux distributions ship a default, some Linux distributions
support a FIPS mode which is what a few get certified. There is another
deployment dear to me that is relevant here, the servers that run Wikipedia.
Distri default: Support a superset of FIPS mode, meaning FIPS off can
connect to a system with FIPS on. This is often broken in that FIPS
algorithms might get preferred where they shouldn't be. Also in practice
people who want to avoid those algorithms would need to configure that
on their own even if they would be fine in not being able to connect to
many websites (due to deployment of FIPS on where not necessary).
Distri FIPS mode:
This switches off some options like the non-hybrid x25519.
This is all the same binaries as the normal / default mode of the Linux
distribution. Except for sometimes special disk images, installer
images, live media images, etc that have the FIPS mode on by default.
There is a kernel boot argument fips=1 which ever supported bootloader
needs to be able to pass to the Linux kernel to boot. Operators can edit
it before the boot and this also applies to live images or installers.
Applications running on linux can read this and everything that uses any
cryptography needs to react to it. It needs to be passed through by any
container like podman/kubernetes/flatpak or virtualization software like
kvm. So any supported container images also need to support FIPS mode.
This is fragile as it involves many manual changes at downstream vendors
and operators and humans make errors all the time. Operators
accidentally run with FIPS mode not enabled. Software is not implemented
to react to FIPS mode. Random example I would expect to fail this is
Chrome/Chromium. Container images often do not consider FIPS mode as
base images who do are bigger. So then security solutions to prevent
those errors get layered on, those are not designed in a secure way and
make the systems even less secure.
Wikipedia: The diversity of clients that needs to be supported is much
bigger. The advantage is that you can just look at the stats on which
negotiation offers where seen in the past as that can be recorded in a
privacy preserving way. The downside is that the pressure to not lock
out a client is bigger than for a Linux distribution (or an Android and
thus client only distribution).
Note that the IANA TLS Parameters page does not express any of these
configuration realities, not as of now and also not in any previous
version. IMHO that is already a security error. The TLS WG should fix
it, so as an implementer it is directly usable for the most common cases.
---
If X25519MLKEM768 were adopted in CNSA2.0, then that would mean a
reduction in common security failures related to FIPS mode.
CSI_CNSA_2.0_FAQ_.PDF thus in effect argues for this, e.g. by warning
against complexity.
If the non-hybrid ml-kem would be made a spec here, my prediction is
that in effect a big portion of the traffic on the internet would be
migrated from X25519MLKEM768 to a non-hybrid. CSI_CNSA_2.0_FAQ_.PDF in
effect argues against this, e.g. by warning of a second migration.
Please kindly CC me or forward a copy if you want to make a response
from me to a list message more likely.
--
Best regards,
Jan Zerebecki
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
