[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

Eliot Lear <[email protected]> Fri, 10 Jul 2026 23:28:32 +0200
Newsgroups	gmane.ietf.tls
Message-ID	<[email protected]>
This is HIGHLY inappropriate.

Eliot


On 10.07.2026 17:06, Jacob Appelbaum wrote:
> Hi Deb,
>
> On 7/10/26 12:25, Deb Cooley wrote:
>
>> 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.
>
> Thanks for clarifying. I think such warnings can have a chilling effect.
> Ken's email suggests that this was not merely hypothetical. It landed
> differently from the regular mailing list conduct reminder text.
>
>> 2a. Recusal: The topic of the working group last call is about a 
>> draft, not about NSA, I perceive no reason to recuse.
>
> Correct me if I am mistaken, but I recall that your IETF biography says
> you spent a major part of your career at NSA namely IAD/CSD. I imagine
> that it is frustrating to hear so much about NSA from people who know
> comparatively little about NSA. It may also feel personal and unfair.
> EKR's point about not making this personal is important, and I want to
> be careful about that.
>
> The issue is not personal. The issue is trust in a standards process.
>
> RFC 7258 is relevant to this draft and to the working group. The entire
> RFC is worth reading, but this is the most compact part:
>
>   To summarise: current capabilities permit some actors to monitor
>   content and metadata across the Internet at a scale never before
>   seen. This pervasive monitoring is an attack on Internet privacy.
>   The IETF will strive to produce specifications that mitigate
>   pervasive monitoring attacks.
>
> That concern is not speculative, and it is not a conspiracy theory. The
> NYT-published SIGINT Enabling budget exhibit says the project "actively
> engages the US and foreign IT industries" to influence commercial
> products and make them exploitable while their security appears intact
> to users and other adversaries [3]. The same reporting and source
> documents describe inserting vulnerabilities into commercial encryption
> systems and influencing commercial public-key standards and
> specifications [3][4][5].
>
> DER SPIEGEL separately reported that documents seen by SPIEGEL showed
> NSA agents traveling to IETF meetings "to gather information but
> presumably also to influence the discussions there" [6]. For
> transparency: I am one of the authors of the cited DER SPIEGEL
> reporting. I am citing it here because the underlying documents and
> reporting are directly relevant to the trust and standards-influence
> issue under discussion. These are documented facts, and NSA justified
> its activities as legal when we asked for comment.
>
> The BULLRUN/TLS documents are not just general history about anti-crypto
> work. The documents we published directly discuss TLS, SSL, IPsec, and
> related operational decryption work. One SSL/TLS document uses the
> phrases "Literally millions of sessions per day" and "need both sides of
> conversation" in the context of SSL/TLS traffic analysis and attack
> workflows for producing decryptions [10]. Another specifically names
> GCHQ work on "TLS trends" in the BULLRUN context [11]. These were TLS
> 1.2-and-earlier era documents; the point here is not that TLS 1.3
> existed then, but 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.
>
> SPIEGEL also reported on Tailored Access Operations (TAO) operational
> work exploiting weaknesses in the IT industry, including attacks against
> network operators, endpoints, and infrastructure [7]. The larger public
> record shows a sustained effort to defeat, weaken, influence, or route
> around deployed cryptography, including TLS/SSL, VPN/IPsec, standards,
> and commercial products [3][4][5][6][7][8][9][10][11].
>
> This is why the topic of any TLS draft intended to secure Internet
> traffic from large-scale third-party adversaries is, unfortunately, more
> than merely adjacent to documented NSA activities. That does not mean
> every former NSA employee is acting improperly.
>
> It does mean that precision about roles, obligations, and limits
> matters. Thus the question is not only whether you personally perceive a
> conflict. It is also whether you can accept that others may reasonably
> perceive one, given the history around Dual_EC_DRBG, NIST/NSA
> cryptographic standards work, and documented NSA efforts to influence
> commercial cryptographic standards. This is also why NSA involvement in
> IETF leadership roles can be controversial. The BULLRUN program's
> standards-influence work was not usually so overt.
>
>> 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.
>
> One clarification, please: do you mean that you have no current
> employment obligations to NSA?
>
> For just one example: one hopes that you are able to read every single
> one of my citations such as [8], [9], [10], and [11] without reporting
> requirements or concerns. It is hard to reach a common understanding 
> if we are not all able to read the same documents.
>
> I ask because former clearance holders generally retain continuing
> nondisclosure obligations regarding classified information after
> retirement. SF 312 says its obligations apply "at all times thereafter"
> unless released in writing by an authorized U.S. Government
> representative, and the ODNI SF 312 FAQ says a prior NDA remains "in
> full force and effect for the lifetime of the individual" [1][2].
>
> The distinction matters here because this discussion is happening
> against a real trust deficit: NIST/NSA history around Dual_EC_DRBG,
> public records about NSA participation in standards work, and documented
> NSA efforts to influence commercial cryptographic standards [3][4][5][6].
>
> Naturally, having a _current_ clearance would be a completely different
> issue. The more that can be stated, the more these concerns can be
> addressed and handled appropriately.
>
> I am not asking you to disclose anything classified. I am asking whether
> "no obligations" means only "no current employment duties," while
> ordinary continuing secrecy obligations still apply.
>
> Congratulations on your retirement, and thank you for your service.
>
> Kind regards,
> Jacob
>
> [0] https://datatracker.ietf.org/doc/html/rfc7258
>
> [1] https://www.gsa.gov/system/files/2024-06/SF312-23.pdf
>
> [2] https://www.dni.gov/files/NCSC/documents/Regulations/
> SF312_Frequently_Asked_Questions_Pamphlet_May_2022_Digital_Signature_Update.pdf 
>
>
> [3] http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-
> nsa-campaign-against-encryption.html?_r=0
>
> [4] http://www.propublica.org/article/the-nsas-secret-campaign-to-crack-
> undermine-internet-encryption
>
> [5] http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-
> codes-security
>
> [6] https://www.spiegel.de/international/germany/inside-the-nsa-s-war-
> on-internet-security-a-1010361.html
>
> [7] https://www.spiegel.de/international/world/the-nsa-uses-powerful-
> toolbox-in-effort-to-spy-on-global-networks-a-940969.html
>
> [8] https://cdn.prod.www.spiegel.de/
> media/45b5a458-0001-0014-0000-000000035509/media-35509.pdf
>
> [9] https://cdn.prod.www.spiegel.de/
> media/25722dbd-0001-0014-0000-000000035510/media-35510.pdf
>
> [10] https://cdn.prod.www.spiegel.de/
> media/52751d2b-0001-0014-0000-000000035511/media-35511.pdf
>
> [11] https://cdn.prod.www.spiegel.de/media/
> cb7c4c91-0001-0014-0000-000000035512/media-35512.pdf
>
>
>> 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 tls- 
>>>> [email protected]
>>>>
>>>>
>>>> _______________________________________________ TLS mailing list -- 
>>>> [email protected] To unsubscribe send an email to tls- [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]
OpenPGP_0x87B66B46D9D27A33.asc (application/pgp-keys, 2.6 KB)
OpenPGP_signature.asc (application/pgp-signature, 495 B)