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

Hi Eliot,

On 7/10/26 23:28, Eliot Lear wrote:
> This is HIGHLY inappropriate.

I disagree. The email is written in a professional and kind manner, it 
is not a personal attack, and it is relevant to the concerns of many 
people on this list. Some of those people have voiced concern that they 
are not able to speak up for fear of reprisals.

Bringing current and former NSA people onboard into the IETF leadership 
presents unique challenges. The IETF should be leading with transparency 
and openness. It's understandable for people to decline to answer but it 
is wrong to say these are somehow inappropriate questions. It is 
inappropriate that we don't know the answers to all of these questions 
(and more) already.

Kind regards,
Jacob Appelbaum

> 
> 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]