Contrary to what readers would expect from a "last call" for objections,
several people (including me) had already filed earlier objections that
haven't been resolved.
It shouldn't be necessary to repeat the objections, but Thomas Bellebaum
promptly replied to the "last call" by highlighting various objections.
That was on the 6th, more than two weeks ago. I've seen no response.
The rest of this message focuses on a different objection, which is that
this document is out of scope for the WG. This document doesn't serve
any of the official goals in the TLS WG charter. Most importantly, this
document is directly contrary to the "improve security" goal, so it
would violate the charter even if it contributed to another goal.
Specifically, the charter
https://web.archive.org/web/20251011020257/https://datatracker.ietf.org/wg/tls/about/
sets three goals for the WG: to improve applicability to "emerging
protocols and use cases"; to "improve security, privacy, and
deployability"; and to maintain the protocol, for example by specifying
general best practices.
TLS is already moving forward with ECC+PQ. This document instead removes
the ECC seatbelt. This will create unnecessary damage if the PQ choice
is broken. Half of the PQ proposals submitted to NIST in 2017 have been
broken already (for details see https://cr.yp.to/papers.html#qrcsp),
often with attacks having sufficiently low cost to demonstrate on
readily available computer equipment. Further PQ software has been
broken by implementation issues such as side-channel attacks (see, e.g.,
https://cr.yp.to/papers.html#kyberslash).
This document is thus directly contrary to the "improve security" goal
in the charter, a goal that one would imagine has very high weight for a
WG on "Transport Layer Security".
There are situations where one can argue that incurring a security risk
is justified by a different goal in the charter---such as deployability,
which is a prerequisite for security. But weakening ECC+PQ to just PQ
isn't enabling deployment.
The main cost of ECC+PQ (see https://blog.cr.yp.to/20240102-hybrid.html
for concrete numbers) is PQ network traffic, not ECC network traffic or
ECC computation. The cost difference between ECC+PQ and PQ is even less
noticeable in the context of overall application costs: for example,
Meta reports spending only 1/2000 of its CPU cycles on X25519, the
dominant ECC choice.
Furthermore, the PQ option isn't in a vacuum: it's an _extra_ option on
top of the existing ECC+PQ. This makes TLS _harder_ to implement, yet
another obstacle to software competition. This _damages_ deployability.
The WG's "use cases" goal allows "protocol changes that reduce TLS
resource consumption without affecting security". That's not the
situation at hand. This document isn't making a security-preserving
protocol change: it's incurring unnecessary security risks by adding new
"groups" that throw away common-sense seatbelts. Furthermore, the change
in resource consumption is so minor that it can't possibly outweigh the
"improve security" goal in the charter.
This document also doesn't fit any of the maintenance subgoals in the
charter. It isn't specifying "general best practices for use of (D)TLS,
extensions to (D)TLS, and cipher suites"; in particular, it's far away
from best practices for cipher suites. The proposal to mark the document
as D wouldn't make the document fit the "when a particular version
should be deprecated" part of the charter: that's about TLS (or DTLS)
versions, not about more specific options.
The document was introduced in pursuit of "CNSA 2.0 compliance", which
can be viewed as a different type of deployability argument:
https://web.archive.org/web/20250613195524/https://mailarchive.ietf.org/arch/msg/tls/qFRxBSnEPJcdlt7MO0cIL2kW5qc/
This seems echoed by unofficial comments from NSA employees, such as a
comment that NSA is "looking for products that support /standalone/
ML-DSA-87 and /standalone/ ML-KEM-1024. If there is one vendor that
produces one product that complies, then that is the product that goes
on the compliance list and is approved for use. Our interactions with
vendors suggests that this won't be a problem in most cases":
https://web.archive.org/web/20250613195524/https://mailarchive.ietf.org/arch/msg/spasm/xUKIoHQwm1BjNZWS2x3xb-BhsLI/
However, NSA has issued various official documents, such as
https://web.archive.org/web/20250827175413/https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
from this year, saying that "hybrid solutions may be allowed or required
due to protocol standards".
If the TLS WG simply holds the line and refuses to standardize
non-hybrid PQ, then NSA's TLS purchasing will be forced to comply,
destroying this deployability argument.
What if, hypothetically, NSA suddenly issues a new official document
saying that it _won't_ obey IETF's TLS standards? The resulting "NSA
demands it, therefore supporting it improves deployability" argument
would still fail to outweigh the damage done to the "improve security"
goal in the charter.
We have already seen many examples where options added because of NSA
pressure continued causing security problems for many years. See, e.g.,
https://publish.illinois.edu/science-of-security-lablet/files/2016/08/10062016-Heninger-Slides.pdf
or Dual EC. TLS 1.3 did better by going beyond removing known failures:
it also tried to proactively eliminate unnecessary risks, for example by
asking for security proofs and, more to the point, taking steps to
remove unnecessary options. Adding new options because of NSA pressure
would be going back to the dark ages where "improve security" was merely
removing known failures.
Furthermore, even if a standard has a completely clear warning saying
"This is a controversial document incurring unnecessary security risks",
most people who make purchasing decisions _won't see that warning_. All
they'll see is that there's a standard. They'll also assume that each
option has a good reason for existence---for example, that an option
providing microbenchmark wins is providing _important_ wins. If the WG
endorses this document then it's begging for bad purchasing decisions.
That's again contrary to the "improve security" goal in the charter.
Finally, given that "Fundamentally, '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 "deployability" wording in the charter has to
be understood as deployability for the whole Internet, not just what
NSA claims is the solution it wants.
---D. J. Bernstein
===== NOTICES =====
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
sentence is the official language from IETF's "Legend Instructions" for
the situation that "the Contributor does not wish to allow modifications
nor to allow publication as an RFC". I'm fine with redistribution of
copies of this document; the issue is with modification.)
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
