Jacob nailed it perfectly [1]:
> The related point is the historical context in Thomas R. Johnson's
> declassified NSA history [0].
>
> The historical pattern is not "make it weak for everyone"; it is "make
> it strong enough for most attackers while preserving an NSA advantage."
>
> Say by leaving out P-521 and then not explaining it.
>
> That is why the Security Considerations could for example provide at least
> plausible deniability.
Quote from the reference [1]:
> (FOUO) Once that decision had been made, the debate turned to the issue of
> minimizing the damage. Narrowing the encryption problem to a single,
> influential algorithm might drive out competitors, and that would reduce the
> field that NSA had to be concerned about. Could a public encryption standard
> be made secure enough to protect against everything but a massive brute force
> attack, but weak enough to still permit an attack of some nature using very
> sophisticated (and expensive) techniques? NSA worked closely with IBM to
> strengthen the algorithm against all except brute force attacks and to
> strengthen substitution tables, called S-boxes. Conversely, NSA tried to
> convince IBM to reduce the length of the key from 64 to 48 bits. Ultimately,
> they compromised on a 56-bit key.
In 2005, the NSA publicly announced Suite B with security levels of 128 and 192
bits of security.
At the same time, the NIST standardized algorithms with security levels of 128,
192, and 256 bits of security.
Projecting the security level of the (classified) Suite A is therefore not
particularly difficult.
The imperialistic machinery is powerful, but also bureaucratic.
Large-scale deployments leave traces, making it easy to read the tea leaves.
As the saying goes, a chain is only as strong as its weakest link.
Since NSA-RFC 9151 (2022) permits only curve P-384, the security level is
reduced to 192 bits, which in my view violates RFC 8890 ("The Internet is for
End Users").
Regarding conflicts of interest, Daniel J. Bernstein posted on his microblog
[2]:
> 2026.07.09 19:12:08: Wait, I undercounted: NSA cast _six_ votes (Mike
> Jenkins, Nicholas Gajcowski, William Layton, Morgan Stern, Peter Yee from
> non-NSA address, Mark Motley from non-NSA address). Looking beyond NSA: DoD's
> Ann Krieger; DoD lifer Major Mike StJohns. Three GCHQ, two CSE, one partridge.
>
> 2026.07.09 16:40:45: IETF TLS WG chairs have closed the vote, and say they'll
> go through https://mailarchive.ietf.org/arch/browse/tls/ "to see what the
> consensus is". Consensus? Each side received more than 80 votes on list:
> e.g., 7 positive votes from DoD, 4 from Cisco, etc. (5 on each side didn't
> give full real names.)
This would imply:
- U.S. intelligence service: 6
- UK intelligence service: 3
- Canadian intelligence service: 2
The NSA-aligned "defense" sector also includes the French Thales Group, with
two votes [3, 4], which, in the first case, appears to have joined solely for
this purpose [5].
(This is business, not personal.)
Not only was the "NIST" working group [email protected] in fact an NSA working
group with "more NSA members than NIST members" [6], but, if Dan's count is
correct, SIGINT agency employees also account for a double-digit percentage of
the votes in favor, based only on those identified so far.
It looks as though the "Five Eyes" (FVEY) really, really, REALLY want to push
this through.
However, the Security Area Director (former lifetime NSA employee) has assured
us that, in her case, there is no conflict of interest.
Nothing to see here!
My bet is on the removal of the hash function.
This would leave the door open to a repeat of the Dual_EC_DRBG backdoor
scenario, either now or at some point in the future.
Kind regards,
Ken Kubota
____________________________________________________
Ken Kubota
https://doi.org/10.4444/100
[1] Thanks to Jacob for the kind permission to quote the offlist email. The
reference is:
> [0] 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, "Public Cryptography".
> https://archive.org/stream/cold_war_iii-nsa/cold_war_iii-ISCAP_djvu.txt
[2] https://microblog.cr.yp.to
[3] https://mailarchive.ietf.org/arch/msg/tls/AMFS3zQ-lwxywlcGBVwAbfIatH4/
[4] https://mailarchive.ietf.org/arch/msg/tls/3CiGJCeWkHGq74sRXC_uwgF_ilw/
[5] https://mailarchive.ietf.org/arch/msg/tls/0iS5oEVYud7j4hjeYUq9IBlNY-E/
[6] https://nist.pqcrypto.org/foia/highlights.html
> Am 11.07.2026 um 13:00 schrieb Ken Kubota <[email protected]>:
>
> "I'm not sure what your point is here"
> 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.
> 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.
>
> In my opinion, the warning email [1] constitutes a violation of RFC 3934
> Section 2, and therefore I asked questions 1, 2, 3, and 4 in the section
> addressed to you [2], which you decided not to answer except for the first
> part of question 1, even though they could be answered with a simple "yes" or
> "no" (or a short sentence).
> This creates the impression that the rules are applied very restrictively to
> some people [3], while not being applied at all to others.
>
> "I have no obligations to them"
> 1. a) Please confirm that you are under neither a contractual obligation nor
> any legal obligation preventing you from freely disclosing information about
> the NSA. b) Please explain why there have been no disclosures comparable to
> Snowden's.
> 2. Edward Snowden left the NSA and publicly released the documents. a) Why
> did you act differently? b) Why have no documents been made public? c) How do
> you support Edward Snowden?
> 3. Do you really think that, after more than 35 years of service, such a
> change in mindset and professional and personal distance is credible at all?
> Following the Snowden disclosures in 2013, you could easily have expressed
> your dismay, even without disclosing documents, by leaving the NSA. You did
> not.
> Let me note that I regard this as a legitimate conflict-of-interest debate
> (therefore not covered by the "impersonal" clause), resulting from the
> pervasive NSA activity in this working group.
>
> Your point 2a. ("is about a draft, not about NSA") is, in my opinion,
> incorrect, as it is too obvious that the NSA is pursuing a hidden agenda here
> (in this working group / on this mailing list) with respect to the draft,
> making it difficult to distinguish between the draft and the NSA.
> Multiple NSA employees (together with some people from the aligned so-called
> "defense" sector) are voting in unison in support of the draft without
> providing any rationale, except for one, which is little convincing (I am
> using very polite words here).
> The background has already been highlighted by Jacob on this mailing list in
> the context of an NSA program: "that TLS has long been a high-value target
> for large-scale cryptographic exploitation. This draft is about a TLS
> specification that will be targeted when deployed on the Internet by the same
> machinery, often improved." [4]
> Clearly, there is an attempt by the NSA to push through this draft here.
> Everybody can see this.
>
> Kind regards,
>
> Ken Kubota
>
> ____________________________________________________
>
> Ken Kubota
> https://doi.org/10.4444/100
>
>
>
> [0] https://www.rfc-editor.org/rfc/rfc8890.html
>
> [1] https://mailarchive.ietf.org/arch/msg/tls/hBFfH4lHo-cLPNfikGfxkoV6hAY/
>
> [2] https://mailarchive.ietf.org/arch/msg/tls/vFu5iq8gPQFByj4L0hkCEAJUR9I/
>
> [3] https://mailarchive.ietf.org/arch/msg/tls/X8-3pmioGxFZX3T0tRsdxPWKx3I/
>
> [4] https://mailarchive.ietf.org/arch/msg/tls/ZWTVxeh52P1LoJEHBJp_WTRsVBA/
>
>
>
>> Am 10.07.2026 um 12:25 schrieb Deb Cooley <[email protected]>:
>>
>> I will only respond to two points (divided):
>>
>> 1. My warning to the list: Indeed, if a 'new participant' violates any of
>> the stated policies, they will receive a private warning before any further
>> action.
>>
>> 2a. Recusal: The topic of the working group last call is about a draft,
>> not about NSA, I perceive no reason to recuse. I will also point out that I
>> am retired from the US Federal Government, and I have no obligations to
>> them, just like any other person changing companies wouldn't retain
>> responsibilities of their previous company.
>>
>> 2b.The RFC 9151 was published in 2022, but in fact was completed much
>> earlier (it had to wait for DTLS 1.3 to be published). I'm not sure what
>> your point is here, but the RFC is a profile of (D)TLS 1.2 and 1.3 for a
>> specific community.
>>
>> 2c. On the subject of general recusal for all things crypt:
>> See: https://mailarchive.ietf.org/arch/msg/ssh/7KRZCX_bvZWUOG50HqDg_KVT77c/
>>
>> If you want a feature request (attach an archive link to an email), I
>> suggest you contact the tools team (https://www.ietf.org/about/groups/tools/
>> ).
>>
>> Deb Cooley
>> Sec AD
>>
>> On Thu, Jul 9, 2026 at 10:48 PM Ken Kubota <[email protected]> wrote:
>> In this message, I am responding collectively to the following emails:
>> - William Layton (NSA)
>> - Deb Cooley (Sec AD)
>>
>> Due to the high volume of traffic from this mailing list, I will create a
>> new email address.
>> I would like to mention this in advance to avoid any misunderstandings, as
>> the new email address will be registered before the current one is removed.
>>
>>
>>
>> William Layton (NSA):
>>
>> On Tue, 07 July 2026 [1]:
>>
>>> The two independent layers is all about implementation, not cryptography.
>>> If you look at the more detailed solutions that implement two layers you'll
>>> see separate boxes with firewalls, intrusion detection, etc. placed between
>>> them. That concept is orthogonal to a discussion of multiple algorithms.
>>
>> My question was:
>>
>>>> Why the apparent change of position?
>>
>>>> In this PDF document, the NSA consistently requires the exact opposite: a
>>>> hybrid approach (two tunnels/layers).
>>
>>
>> 1. The concept of a (parallel) hybrid approach is to safeguard against
>> failure of a single component. Whether the hybrid approach is applied across
>> implementation boundaries or across cryptographic algorithms is irrelevant
>> to the nature of the hybrid approach.
>> In this case, it safeguards against any (future) compromise of ML-KEM (or
>> weaknesses associated with it) by also using ECC.
>> Therefore, the distinction between implementation and cryptography is
>> irrelevant in this context.
>>
>> 2. Post-quantum algorithms are immature. RFC 9958 (Post-Quantum Cryptography
>> for Engineers) [2] from June 2026: "the post-quantum algorithms face
>> uncertainty about the underlying mathematics, compliance issues, unknown
>> vulnerabilities, and hardware and software implementations that have not had
>> sufficient maturing time to rule out traditional cryptanalytic attacks and
>> implementation bugs."
>> ECC was far better understood and studied at the time it was standardized.
>> I myself found it surprising how quickly the NIST PQC standardization
>> process took place. The subsequent cryptanalytic breaks of several
>> algorithms, including a finalist, are therefore less surprising.
>>
>> 3. SIKE, a NIST finalist, was shown to be breakable in 2022, only four years
>> ago. Under these circumstances, cutting away the second safety belt
>> introduces unnecessary risk.
>>
>> 4. Moreover, contrary to the explicit recommendation of one of the authors
>> of ML-KEM/Kyber (Peter Schwabe), the hash was removed even though it would
>> help protect against attacks such as the NSA's Dual_EC_DRBG backdoor, which
>> NIST was ultimately forced to remove: "Should those RNGs include the hash?
>> Yes, of course. [...] Of course, as you stated in a another message, the RNG
>> output may leak through all kind of other sources, but the hash in Kyber's
>> Ecnaps is a cheap "defense-in-depth" mechanism to ensure that we don't add
>> another source of leakage." [3]
>> As the Kyber author mentions correctly, adding the hash is inexpensive, and
>> removing it without a compelling justification raises legitimate concerns.
>> Given that the NSA's contribution was never disclosed ("The FOIA results
>> show that what NIST publicly labeled as the "Post Quantum Cryptography Team,
>> National Institute of Standards and Technology (NIST), [email protected]"
>> actually had more NSA members than NIST members." [4]), these circumstances
>> warrant careful scrutiny.
>>
>> 5. Anything other than using a hybrid approach here is difficult to justify
>> from a cryptographic perspective.
>> This is especially true given the risks outlined above.
>> For these reasons, the hybrid approach is explicitly recommended in RFC 9958
>> (Post-Quantum Cryptography for Engineers) Section 15.4. [5]: "Hybrid key
>> exchange is recommended to enhance security against the HNDL attack.
>> Additionally, hybrid signatures provide for time to react in the case of the
>> announcement of a devastating attack against any one algorithm, while not
>> fully abandoning traditional cryptosystems."
>>
>> 6. Virtually everyone else has also chosen a hybrid approach.
>> Not only did OpenSSH adopt a hybrid approach by default in 2022 ("use the
>> hybrid Streamlined NTRU Prime + x25519 key exchange method by default
>> ("[email protected]")" [6]), but it also adopted another
>> hybrid scheme only a few days ago ("OpenSSH 10.4 was released on 2026-07-06.
>> [...] add experimental support for a composite post-quantum signature scheme
>> that combines ML-DSA 44 and Ed25519" [7]).
>> Germany's NIST counterpart, the BSI, reaches the same conclusion. Technical
>> Guideline TR-02102-2 (version 2026-01): "The BSI intends to recommend the
>> quantum-safe hybrid key agreement mechanisms SecP256r1MLKEM768 and
>> SecP384r1MLKEM1024 from the Internet-Draft at
>> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ as soon as the
>> corresponding RFC has been adopted." [8]
>> BSI TR-02102-1 (version 2026-01): "The quantum-safe mechanisms recommended
>> in this Technical Guideline are generally not yet trusted to the same extent
>> as the established classical mechanisms, since they have not been as well
>> studied with regard to side-channel resistance and implementation security.
>> To ensure the long-term security of a key agreement, this Technical
>> Guideline therefore recommends the use of a hybrid key agreement mechanism
>> that combines a quantum-safe and a classical mechanism. An obvious
>> hybridization is to perform two key agreements in parallel and to derive a
>> combined key from the generated key material." [9]
>>
>>
>> There are multiple significant warning signs.
>>
>>
>> I can only respond intermittently, and lack of response, even for a longer
>> time, does not mean endorsement. Currently, my resources are outmatched by
>> those of the NSA.
>>
>>
>>
>> Deb Cooley (Sec AD):
>>
>> On Tue, 07 July 2026 15:55 UTC [10]:
>>
>>> This is a public warning to the entire TLS working group, in accordance
>>> with RFC 3934 Section 2 [0].
>> [...]
>>> *not participating in ad hominum attacks (veiled or unveiled)
>>> *not sending multiple responses in quick succession
>>
>> On Tue, 07 July 2026 17:37 UTC [11]:
>>
>>> I will only engage on a couple of points:
>>>
>>> 1. Obviously those participants who have been contributing in good faith
>>> have nothing to worry about.
>>>
>>> 2. The new participants should read the rules prior to posting, this
>>> warning will help them understand what is expected.
>>
>> RFC 3934 Section 2 [12] explicitly states that a public warning is the
>> second step after communicating directly with the offending individual:
>> "Unless the disruptive behavior is severe enough that it must be stopped
>> immediately, the WG chair should attempt to discourage the disruptive
>> behavior by communicating directly with the offending individual. If the
>> behavior persists, the WG chair should send at least one public warning on
>> the WG mailing list."
>>
>> I feel it necessary to seek clarification, since the warning and the
>> subsequent email referring to "[t]he new participants" (plural) were issued
>> shortly after I entered the mailing list and someone accused me of an ad
>> hominem attack, although my point clearly concerned a potential conflict of
>> interest related to NSA activity on this mailing list, and, in that context,
>> specific actions (or failures to act) by NSA employees [13].
>>
>> Andrew Lee made a point [14] with which I agree and which I would rephrase
>> as follows: an indiscriminate warning can have an intimidating effect and
>> therefore is detrimental to an open discussion.
>> The same holds for any vagueness in the interpretation of rules.
>>
>> He also wrote:
>>>> *not sending multiple responses in quick succession
>>>
>>> Participants on both sides have posted multiple messages throughout this
>>> WGLC. This standard has never previously been cited or enforced. Further,
>>> this warning starves debate during a WGLC; whether that's intentional or
>>> not doesn't matter.
>>
>> To avoid intimidation and ensure the fair application of the rules, all
>> parties should strictly adhere to the RFCs and avoid any uncertainty caused
>> by vague wording.
>>
>> My understanding is the following:
>>
>> 1. RFC 3934 Section 2 states that, in the case of disruptive behavior, the
>> WG (working group) chair should first contact the individual directly.
>> Ideally, the relevant passage should be quoted and the reason explained.
>>
>> 2. RFC 3934 Section 2 states that a public warning should be issued by the
>> WG chair only as a second step, and the wording implies that the individual
>> should be identified in the public warning (and also not to intimidate
>> others).
>>
>> 3. RFC 3934 Section 2 states that neither individual correspondence nor a
>> public warning should be conducted by the AD (Area Director), but by the WG
>> chair.
>>
>> 4. RFC 3934 Section 2 does not state that "new participants" should be
>> greeted with a warning message.
>>
>> 5. The term "contributing in good faith" is subject to interpretation, and
>> in order to avoid intimidation, any person to be warned should be mentioned
>> by name instead. For example, not only many researchers, but probably the
>> majority of the world population would reasonably question whether the
>> pervasive NSA presence in this working group qualifies as "contributing in
>> good faith."
>>
>> 6. Discussions about conflict of interest related to the NSA, including
>> their behavior on this mailing list with regard to a potential conflict of
>> interest - as NSA employees, not as members of a specific ethnicity or some
>> other outward property - constitute neither an ad hominem attack nor some
>> other violation of any rule.
>>
>> 7. The criterion "not sending multiple responses in quick succession" is not
>> part of any RFC, as the RFCs define criteria based on content rather than
>> frequency (e.g., RFC 3683 Section 1 [15] mentions "unsolicited bulk e-mail"
>> or "discussion of subjects unrelated to IETF policy" etc.). (If a numerical
>> criterion is unavoidable, it should be exactly defined, e.g., more than two
>> emails per hour.) I find such a vague formulation problematic, as I
>> sometimes edit several emails in parallel, and later send them at the same
>> time, which would formally satisfy the criterion "sending multiple responses
>> in quick succession" although my overall email volume is no higher than that
>> of others.
>>
>> 8. An AD (Area Director) who has retired from the NSA after 35+ years no
>> less than three years ago [16] and published RFC 9151 in 2022 as an NSA
>> employee [17] would present a conflict of interest when dealing with
>> questions concerning the NSA, including whether a debate constitutes a
>> legitimate discussion of a conflict of interest related to the NSA. In such
>> a case, that AD should therefore recuse themselves in accordance with RFC
>> 7776 Section 7 (Conflicts of Interest) [18]: "Furthermore, a conflict of
>> interest arises if the person involved in the process of handling a
>> harassment report is closely associated personally or through affiliation
>> with any of the Reporter, Respondent, or Subject. / For the avoidance of
>> doubt, recusal in this context means completely stepping out of any advisory
>> or decision-making part of any process associated with handling a harassment
>> report, remedy arising from a harassment report, or appeal into the handling
>> of a harassment report. That means that a recused person has no more right
>> to participate in or witness the process than any other person from the
>> community in the same situation." One example of a potential conflict of
>> interest is the publication of an RFC authored solely by an NSA employee
>> [17]. When NSA announced Suite B Cryptography in 2005 and published the
>> corresponding webpage in 2009 [19], the obvious strategy was to make the
>> security levels of 128 bits of security (e.g., curve P-256) and 192 bits of
>> security (e.g., curve P-384) publicly available as Suite B, but withhold the
>> security level of 256 bits of security (e.g., curve P-521) as part of Suite
>> A [19, 20, 21]. (From the beginning, only AES-256 was used to "to enhance
>> interoperability" [22], and in August 2015, the security level of 128 bits
>> of security was removed [23].) 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. 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. RFC
>> 8890 clearly says "The Internet is for End Users" [26], and this means
>> strong cryptography (256 bits of security) should be available for everyone.
>> Notably, Bernstein explicitly praises curve P-521 (256 bits of security):
>> "To be fair I should mention that there's one standard NIST curve using a
>> nice prime, namely 2^521−1" [27].
>>
>>
>> Please confirm this understanding or, if you disagree, provide an
>> explanation or clarification.
>>
>>
>> It would be helpful if every email received from the mailing list included a
>> permanent archive link in its signature, so that participants do not have to
>> search the archives manually when quoting previous messages.
>>
>>
>> Kind regards,
>>
>> Ken Kubota
>>
>> ____________________________________________________
>>
>> Ken Kubota
>> https://doi.org/10.4444/100
>>
>>
>>
>> [1] https://mailarchive.ietf.org/arch/msg/tls/5lGA_ObJ5Z58PqIRyF8nC3Lj1Po/
>>
>> [2]
>> https://www.rfc-editor.org/rfc/rfc9958.html#name-post-quantum-and-traditiona
>>
>> [3]
>> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/o2XJ2YvfAwAJ
>>
>> [4] https://nist.pqcrypto.org/foia/highlights.html
>>
>> [5]
>> https://www.rfc-editor.org/rfc/rfc9958.html#name-hybrid-key-exchange-and-sig
>>
>> [6] https://www.openssh.org/txt/release-9.0
>>
>> [7] https://www.openssh.org/txt/release-10.4
>>
>> [8]
>> https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=11#page=12
>>
>> [9]
>> https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile&v=14#page=29
>>
>> [10] https://mailarchive.ietf.org/arch/msg/tls/hBFfH4lHo-cLPNfikGfxkoV6hAY/
>>
>> [11] https://mailarchive.ietf.org/arch/msg/tls/X44P3cF-H4s8kX-RzyZEeQYTkbo/
>>
>> [12] https://www.rfc-editor.org/rfc/rfc3934.html#section-2
>>
>> [13] https://mailarchive.ietf.org/arch/msg/tls/xTiYQnK8uS181kRlFe7xiFjdD20/
>>
>> [14] https://mailarchive.ietf.org/arch/msg/tls/LvUiinuyMPCXTFMrbeYB0aa1Iw4/
>>
>> [15] https://www.rfc-editor.org/rfc/rfc3683.html#section-1
>>
>> [16] https://datatracker.ietf.org/person/Deb%20Cooley
>> "Deb Cooley
>> Pronouns: she/her
>>
>> Retired Senior Cryptographic Vulnerability Analyst, National Security Agency
>> Cybersecurity Directorate (NSA/CSD) with 37+ years of service in Dec 2023.
>> Most of Deb’s career was spent as a security evaluator on many different
>> technologies including IP encryptors, satellites, radios, and key management
>> devices.
>>
>> Previously, Special Government Expert for the Department of Homeland
>> Security, Cybersecurity and Infrastructure Security Agency’s Cyber Security
>> Division. Previously, acme working group chair."
>>
>> [17] https://www.rfc-editor.org/rfc/rfc9151.html
>> "Published: April 2022
>> Author: D. Cooley
>> NSA"
>>
>> "Author's Address
>>
>> Dorothy Cooley
>> National Security Agency
>> Email: [email protected]"
>>
>> [18] https://www.rfc-editor.org/rfc/rfc7776.html#section-7
>>
>> [19]
>> https://web.archive.org/web/20090117004931/http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
>>
>> [20]
>> https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-56ar.pdf#page=30
>>
>> [21]
>> https://csrc.nist.gov/files/pubs/fips/186-3/final/docs/fips_186-3.pdf#page=101
>>
>> [22]
>> https://web.archive.org/web/20090117004931/http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
>> "1. CNSSP-15 correctly states that 192-bit AES keys are sufficient for
>> protecting even TOP SECRET information. However, Suite B uses only 256-bit
>> keys to enhance interoperability."
>>
>> [23]
>> https://web.archive.org/web/20150815072948/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
>>
>> [24] https://www.rfc-editor.org/rfc/rfc9151.html#section-5.1
>>
>> [25] https://www.rfc-editor.org/rfc/rfc9151.html#section-8
>>
>> [26] https://www.ietf.org/rfc/rfc8890.html
>>
>> [27]
>> https://web.archive.org/web/20260628050821/https://blog.cr.yp.to/20140323-ecdsa.html
>>
>>
>>
>>> Am 07.07.2026 um 23:54 schrieb [email protected]
>>> <[email protected]>:
>>>
>>> The two independent layers is all about implementation, not cryptography.
>>> If you look at the more detailed solutions that implement two layers you'll
>>> see separate boxes with firewalls, intrusion detection, etc. placed
>>> between them. That concept is orthogonal to a discussion of multiple
>>> algorithms.
>>>
>>> Get Outlook for Android
>>>
>>> From: Ken Kubota <[email protected]>
>>> Sent: Tuesday, July 7, 2026 5:47:51 PM
>>> To: William Layton (GOV) <[email protected]>
>>> Cc: [email protected] <[email protected]>
>>> Subject: Re: [TLS] WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
>>>
>>> Why the apparent change of position?
>>>
>>> In this PDF document, the NSA consistently requires the exact opposite: a
>>> hybrid approach (two tunnels/layers).
>>>
>>> "The security against a passive attack targeting Data in Transit
>>> (DiT) across Public Black networks is provided by the layered
>>> encryption of two independent tunnels (Inner and Outer)
>>> using a specific selection of security protocols as instructed
>>> in each CP. The two independent Encryption Components
>>> provide confidentiality and high-level assurance for the
>>> solution, because the adversary should never be able to
>>> exploit a single cryptographic implementation to
>>> compromise both tunnels.
>>>
>>> Two layers of Data at Rest (DAR) Commercial National Security
>>> Algorithm (CNSA) encryption are employed to provide
>>> confidentiality and mitigate passive attacks of stored data.
>>> The DAR components are independent in a number of ways
>>> to mitigate the ability of an adversary to exploit a single
>>> cryptographic implementation to compromise both layers."
>>>
>>> This document is available at:
>>> https://web.archive.org/web/20260425180701/https://www.nsa.gov/portals/75/documents/resources/everyone/csfc/threat-prevention.pdf
>>>
>>> It is also still available on the NSA website.
>>>
>>> Originally referenced in:
>>> https://mailarchive.ietf.org/arch/msg/spasm/ytjNpbERE-YgKw-7c_w-ZRUA1Fw/
>>>
>>> The questions raised there remained unanswered:
>>> https://mailarchive.ietf.org/arch/msg/spasm/WJMl6inph8t8m898kcBzhpWZC0o/
>>>
>>> Kind regards,
>>>
>>> Ken Kubota
>>>
>>> ____________________________________________________
>>>
>>> Ken Kubota
>>> https://doi.org/10.4444/100
>>>
>>>
>>>
>>> Am 07.07.2026 um 22:08 schrieb [email protected]
>>> <[email protected]>:
>>>
>>> I support publication.
>>> Implementors will make their own decisions. This algorithm choice looks
>>> likely to be implemented in multiple places, so having clear documentation
>>> of both security considerations and technical details (as provided by the
>>> draft) is worthwhile for those who might choose to use it.
>>>
>>> -Bill
>>> _______________________________________________
>>> TLS mailing list -- [email protected]
>>> To unsubscribe send an email to [email protected]
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list -- [email protected]
>>> To unsubscribe send an email to [email protected]
>>
>> _______________________________________________
>> TLS mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
