> implementers can make their own choices
This document was introduced in pursuit of "CNSA 2.0 compliance". A
Cisco employee wrote "that's what they're willing to buy. Hence, Cisco
will implement it". An NSA employee wrote (on LAMPS) "As the CNSA 2.0
profiles should make clear, we are 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."
These compliance arguments sound to me like very much the opposite of
implementors making their own choices.
What's really fascinating about this situation is that all of these
compliance claims are contradicted by an official NSA statement
https://web.archive.org/web/20250827175413/https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
saying that "hybrid solutions may be allowed or required due to protocol
standards". If the WG standardizes ECC+PQ and refuses any endorsement of
non-hybrid PQ, what exactly is the supposed compliance problem?
There would be a clear compliance argument if, hypothetically, NSA were
to suddenly announce that it will use its market-warping power to force
non-hybrid PQ _even if this violates standards_. But I think this would
be a public-relations problem for NSA. Instead NSA's official position
is that "hybrid solutions may be allowed or required due to protocol
standards". The hints to the contrary are coming _unofficially_ from
some NSA employees, without the organization taking responsibility.
---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. Legend language
also appears in, e.g., RFC 5831. For further background on the relevant
IETF rules, see https://cr.yp.to/2025/20251024-rules.pdf.)
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
