Hi Eliot, On 7/11/26 14:06, Eliot Lear wrote:
You've misunderstood RFC 9151.
You've misunderstood Ken, I think. There are at least two separate issues here: what RFC 9151 says, and what Ken infers from it. I will limit this reply to RFC 9151 and the directly related policy point. Ken wrote:
Although strong cryptography (256 bits of security) could generally have been available for every end user for the past two decades on standard consumer devices, the U.S. government is intentionally deploying, through the NSA, degraded (weakened) encryption. RFC 9151 (2022), which provides only 192 bits of security (curve P-384), is one example.
I agree that "provides only 192 bits of security" is too broad if read as a description of the whole RFC. RFC 9151 also specifies AES-256-GCM, SHA-384, and RSA/DH with 3072-bit or 4096-bit moduli [0]. But Ken's ECC point is in on the curve(s): RFC 9151 lists only P-384 / secp384r1 for CNSA ECC use, says CNSA (D)TLS connections MUST use secp384r1, and does not include P-521 [1]. So RSA-3072/RSA-4096 does not answer the ECC-profile question. It only shows that the profile also has non-ECC options.
What RFC 9151 and friends say is, "here is how *commercial* entities should *interoperate* with the USG infrastructure".
Your summary is close, but doesn't match the RFC's own text. RFC 9151 says the profile applies to components of US National Security Systems, is also appropriate for other US Government systems that process high- value information, and is made publicly available for developers and operators of "these and any other system deployments" [2]. It also says NSA is authoring these RFCs to provide guidance to vendors and the Internet community in general [3]. So yes, USG/NSS interoperability is central. But the RFC is not framed only as advice for commercial entities talking to USG infrastructure. It also is the case that commercial entity decisions contribute to the shape of the mass market options available to end users.
And it's not just ECDSA with P-384, but also RSA with either 3072 or 4096 bits. Weak indeed.
Correct that RFC 9151 includes RSA with 3072-bit or 4096-bit moduli. Section 5.2 says CNSA specifies a minimum RSA modulus size of 3072 bits, and that this profile supports only 3072 and 4096 [0]. But that does not refute Ken's specific observation that the ECC side is P-384 only. Section 5.1 has exactly one ECC curve row: P-384 / nistp384 / secp384r1 [1]. Ken also wrote:
This may explain why RFC 9151 Section 5.1 [24] lists only curve P-384 (192 bits of security) as the sole acceptable curve without providing a rationale in Section 8 (Security Considerations) [25] for this limitation.
That part seems mostly correct. Section 8 says CNSA implementations MUST only use the curves, RSA schemes, and finite fields defined in Sections 5.1, 5.2, and 5.3, and that otherwise security might be weaker [4]. It does not explain why P-384 is the only ECC curve, nor why P-521 is not included. We aren't even getting into the NIST curve details. Ken also wrote:
While providing a minimum security (a lower bound) for commercial applications is a legitimate concern, establishing a limitation (an upper bound) by withholding 256 bits of security is not.
"Withholding" is an inference, not something RFC 9151 says. But the underlying profile fact remains: RFC 9151 specifies a single ECC curve, P-384, and not P-521 [1]. The policy question is whether that profile is setting a minimum, a maximum, or both. Ken also wrote:
This is contrary to RFC 8890 ("The Internet is for End Users"), which I interpret as meaning that U.S. government interests must not take precedence over those of end users (i.e., human beings, mankind). Strong cryptography (256 bits of security) should be available to everyone.
I read this as explicitly Ken's interpretation of RFC 8890 which as a reader is a fair reading of the text. RFC 8890 does not itself answer which curve must be used. It does, however, support asking whether a public Internet profile primarily serves end users, interoperability with USG/NSS systems, or both [6]. There is also historical context for why "Weak indeed" does not answer the concern. In Thomas R. Johnson's declassified NSA history, published by NSA's Center for Cryptologic History, the DES debate is described as one of "minimizing the damage" from public cryptography. Johnson writes that it was important that a single cryptographic algorithm "drive out competitors", and that it was equally important that the algorithm be "secure enough to provide good security for its intended users, but weak enough for NSA, with its sophisticated techniques, to break if the algorithm were encountered in a SIGINT target." Johnson then says NSA worked closely with IBM, tried to reduce the key length from 64 to 48 bits, and finally compromised on a 56-bit key [7][8]. The usual response is that NSA also helped strengthen the DES S-boxes. That is true, and Johnson says so. It is also not responsive to the key point: the same passage says NSA strengthened DES against attacks other than brute force while also trying to reduce the key length [8]. In other words, the historical pattern is not simply "make it weak for everyone"; it is "make it strong enough for most attackers while preserving an advantage for NSA." That is the point Ken is gesturing at. The very notion of Export Cryptography is a parallel strategy which is fair to characterize as "make it weak for everyone" - and a lot of people went along with that nonsense. Why do we suppose that cryptography was weaker? Weaker in a relevant way to... cryptographic attacks by NSA and other large-scale Adversaries, right?
Regardless, if you're not talking to the USG, have a party. Use whatever suite floats your boat.
That is true in the sense that RFC 9151 is Informational, published in the Independent Submission stream, and not an IETF Standards Track specification [5]. It is not a general IETF mandate. But the Independent Submission stream is not irrelevant. As I understand it, you are the current Independent Submissions Editor, and you were appointed shortly before RFC 9151 was published [9][10]. If I have the timing or your role with this particular RFC wrong, please correct me. It seems odd to not mention that but I guess we all know, and only a person outside the IETF might miss that detail. I feel confident that you are aware of these issues and I appreciate that you engage on the topic. That is really in the spirit of the IETF which is a remarkable contrast to the NIST approach seen in the last few days. Thank you! Either way, this is a public cryptographic profile for TLS, authored by NSA, published as an RFC, and squarely within the TLS community's technical domain. So Ken's question is fair even if one rejects his conclusion: why do the Security Considerations not explain why the ECC profile stops at P-384 and omits P-521? If I have correctly understood Ken's concern(s) then it is fair to say that it is not only "am I forced to use this RFC?" It is also about what NSA-authored public cryptographic profiles recommend, omit, and normalize. On that narrower point, RFC 9151 really does profile CNSA (D)TLS ECC down to P-384 only, while leaving P-521 out. Finally, "if you do not like it, do not use it" does not really fit government infrastructure. Many people have no meaningful choice about using government systems: citizens, residents, contractors, researchers, students, travelers, journalists, diplomats, immigrants, and expats all have to interact with such systems as part of ordinary life. A party is only a party when attendance is optional; otherwise, it is worth asking why the host quietly removed the strongest option from the menu. Kind regards, Jacob [0] https://datatracker.ietf.org/doc/html/rfc9151#section-5.2 [1] https://datatracker.ietf.org/doc/html/rfc9151#section-5.1 [2] https://datatracker.ietf.org/doc/html/rfc9151#section-1 [3] https://datatracker.ietf.org/doc/html/rfc9151#section-2 [4] https://datatracker.ietf.org/doc/html/rfc9151#section-8 [5] https://datatracker.ietf.org/doc/html/rfc9151 [6] https://www.rfc-editor.org/rfc/rfc8890.html [7] Thomas R. Johnson, American Cryptology during the Cold War, 1945-1989, Book III: Retrenchment and Reform, 1972-1980, NSA Center for Cryptologic History, 1998, DOCID 523696. See "Public Cryptography". [8] https://archive.org/stream/cold_war_iii-nsa/cold_war_iii-ISCAP_djvu.txt [9] https://www.ietf.org/blog/new-ise-eliot-lear/ [10] https://datatracker.ietf.org/person/lear%40lear.ch _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
