[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)
Jacob Appelbaum <[email protected]> Sat, 11 Jul 2026 15:50:21 +0200
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <[email protected]> |
Hi John and Ken,
On 7/11/26 13:32, John Mattsson wrote:
> Can we _please_ follow EKR's suggestion and move this discussion to
> a different mailing list? The fact that SIGINT agencies have
> systematically weakened standards to facilitate interception is a
> fact,
John, I am relieved that we can agree on "the fact that SIGINT agencies
have systematically weakened standards to facilitate interception". I
hope everyone in this working group takes note of that point. Thank you
for stating it clearly.
For the sake of constructive clarity and to seek understanding, which
mailing list do you think fits for large-scale adversary attacks against
the TLS protocol?
> but it has very little to do with TLS.
I disagree. It has quite a lot to do with TLS.
Ken referenced my earlier email, which cited documents and reporting
about TLS, SSL, IPsec, and related operational decryption work. The
BULLRUN material is not merely general background about intelligence
agencies and cryptography. Some of the released documents specifically
discuss TLS/SSL workflows at scale, including phrases such as "Literally
millions of sessions per day" and "need both sides of conversation"
[0]. Another document specifically names "TLS trends" in the BULLRUN
context [1]. These were TLS 1.2-and-earlier era documents; the point is
not that TLS 1.3 existed then, but that TLS has long been a high-value
target for large-scale cryptographic exploitation.
This also includes reporting that NSA employees attended IETF meetings
"to gather information but presumably also to influence the discussions
there" [12]. I understood that this is part of where we agree when you
said "the fact that SIGINT agencies have systematically weakened
standards to facilitate interception". Or do you disagree with those
specific facts?
So I do not think it is enough to say that systematic weakening of
standards for interception has "very little to do with TLS". Please make
that case against the actual record: the slide decks, classification
guides, reporting, official strategy documents, and academic analyses.
If you disagree with the relevance of those materials to TLS, please say
which ones and why.
The same point applies to telecom infrastructure. The Athens Affair, as
I cited, showed illegal wiretapping of the Greek prime minister and
other senior officials using telecommunications equipment supplied by
Ericsson; the death of Vodafone engineer Costas Tsalikidis is part of
the public record, although his involvement in the case has not been
established [2]. The operation codenamed OPERATION SOCIALIST is also
relevant context: reporting and later Belgian prosecutorial material
described GCHQ hacking Belgacom, now Proximus, Belgium's largest
telecommunications operator, with a focus on systems and services
relevant to international roaming and European institutions [3][4][5][6].
That history does not prove any claim about this ML-KEM draft by itself.
It does show why dismissing standards-influence and large-scale
interception concerns as unrelated to TLS is not persuasive.
> The few technical arguments presented are as wrong as they can be.
Please identify them precisely. A sentence like this is not a technical
argument.
As the saying goes: "Every man has a right to his own opinion, but no
man has a right to be wrong in his facts" [7][8].
>> 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.
>
> X25519 provides 128-ish bits of security. By the same logic,
> Bernstein is intentionally deploying even more degraded (weakened)
> encryption... sigh...
That does not address Ken's actual claim.
I would separate the factual claims from the policy conclusion. The
factual claims are relatively easy to discuss:
1. RFC 9151 is an NSA-authored CNSA profile for TLS and DTLS 1.2 and
1.3, published as an Informational RFC, and it specifies P-384 as
the acceptable elliptic curve for CNSA-compliant TLS use [9].
2. RFC 7748 describes Curve25519 as targeting the "~128-bit security
level" [10].
3. The policy question is whether choosing or recommending particular
security levels is appropriate for the use case and the threat model.
Your X25519 comparison addresses point 2. It does not by itself answer
Ken's point about NSA/NIST choices, CNSA profiling, or whether a profile
should limit or merely require a minimum security level. It is also
worth noting that Bernstein is not an author of RFC 7748; that RFC is an
IETF/IRTF document with named authors from Google, Rambus Cryptography
Research, and sn3rd, the latter is an affiliation of one of the TLS
chairs. So while Bernstein is clearly endorsing its use, the IETF has
made this policy. If the IETF is wrong, well, then perhaps it is wrong
twice.
> (Note that the 128-ish bits of security provided by X25519 is more
> than sufficient against current classical attackers, and unless
> there are unknown attacks, no SIGINT agency will be able to break
> it with classical computers for many decades.)
Maybe. I agree that X25519 is generally understood as a strong and
appropriate choice for many present-day classical threat models.
But "unless there are unknown attacks" is doing significant work in that
sentence. Logjam is a useful reminder that TLS history includes attacks
where protocol choices, legacy cryptographic policy, common deployment
patterns, and large-scale adversary economics intersected badly [11].
That does not mean X25519 is weak. It means that dismissing concerns
about standards choices with a generic security-level statement is not
enough. In this specific case, X25519 is also not providing a
cryptographic oracle that preserves Dual_EC_DRBG-shaped algebraic
structure.
A more productive framing would be:
- Which threat model are we discussing?
- Are multi-target attacks relevant?
- Are long-term confidentiality and harvest-now-decrypt-later relevant?
- Is the profile setting a minimum, a maximum, or both?
- Is the goal interoperability, national-security compliance, public
Internet guidance, or all of the above?
If your view is simply that these security levels are fine for the
relevant threat model, then that is a clear position. We may disagree,
but at least we would be disagreeing about the right question.
The same applies to ML-KEM in draft-ietf-tls-mlkem-*. Please address the
narrow technical claim: removing Kyber's `m <- H(m)` step preserves
Dual_EC_DRBG-shaped algebraic structure for the decapsulating peer when
`m` is raw output from such an RNG; restoring the hash destroys that
structure. The reason this is possible is that the party that calls
ML-KEM.Encaps() uses raw RNG output as `m` as _required by the NIST FIPS
203 specification_, and `m` is then used as the plaintext input to the
internal public-key encryption step. The party with the corresponding
ML-KEM secret key can run ML-KEM.Decaps(), instrument the internal
decapsulation path, and save intermediate values needed to mount this
attack. If NIST had not removed the hash, ML-KEM.Encaps() would instead
use a hashed value, destroying the algebraic structure that makes
Dual_EC_DRBG exploitation efficient. If that technical claim is wrong,
please show where.
The goal should not be to win a mailing-list exchange. The goal should
be to converge on objective, checkable facts and improve security for
end users. That is the part that matters for the IETF.
Kind regards,
Jacob Appelbaum
[0] https://cdn.prod.www.spiegel.de/
media/52751d2b-0001-0014-0000-000000035511/media-35511.pdf
[1] https://cdn.prod.www.spiegel.de/media/
cb7c4c91-0001-0014-0000-000000035512/media-35512.pdf
[2] https://spectrum.ieee.org/the-athens-affair
[3] https://www.spiegel.de/international/europe/british-spy-agency-gchq-
hacked-belgian-telecoms-firm-a-923406.html
[4] https://www.spiegel.de/fotostrecke/photo-gallery-operation-
socialist-fotostrecke-101663.html
[5] https://www.theguardian.com/uk-news/2018/sep/21/british-spies-
hacked-into-belgacom-on-ministers-orders-claims-report
[6] https://cyber-peace.org/wp-content/uploads/2015/01/Operation-
Socialist_-How-GCHQ-Spies-Hacked-Belgium%E2%80%99s-Largest-Telco.pdf
[7] https://quoteinvestigator.com/2020/03/17/own-facts/
[8] https://quoteinvestigator.com/2020/03/17/own-facts/
#f30770ab-1bd4-47ab-96ac-519429e696fa
[9] https://www.rfc-editor.org/rfc/rfc9151.html
[10] https://www.rfc-editor.org/rfc/rfc7748.html
[11] https://weakdh.org/
[12] https://www.spiegel.de/international/germany/inside-the-nsa-s-war-
on-internet-security-a-1010361.html
> Cheers, John Preuß Mattson
>
> From: Ken Kubota <[email protected]> Date: Saturday, 11 July 2026 at
> 13:09 To: Deb Cooley <[email protected]> Cc:
> [email protected]
> <[email protected]>; [email protected]
> <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-
> mlkem-08 (Ends 2026-07-08)
>
> [You don't often get email from [email protected]. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> "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://eur02.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fdoi.org%2F10.4444%2F100&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579701109%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=sZcJTAoLmzJo1fu6%2BounmJ%2FrTumLNt2Fq5RcOL9nrsc%3D&reserved=0<https://
> doi.org/10.4444/100>
>
>
>
> [0] https://eur02.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fwww.rfc-
> editor.org%2Frfc%2Frfc8890.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579726962%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=29I0ELBzYsGrqFZwMvo%2BRt2w6oOTjKK7P6XRWm%2BDTgU%3D&reserved=0<https://
> www.rfc-editor.org/rfc/rfc8890.html>
>
> [1] https://eur02.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FhBFfH4lHo-
>
>
>
>
>
> cLPNfikGfxkoV6hAY%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579743990%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=RPqetK7qqTRhV1%2B18wQwe17Gaq8zq5zkO6JNe2AV7DY%3D&reserved=0<https://
> mailarchive.ietf.org/arch/msg/tls/hBFfH4lHo-cLPNfikGfxkoV6hAY/>
>
> [2] https://eur02.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FvFu5iq8gPQFByj4L0hkCEAJUR9I%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579763931%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=QZQxAoHn%2Fve3nTu564tG3s2On2lwes5ZgUG8SdNcWzk%3D&reserved=0<https://
> mailarchive.ietf.org/arch/msg/tls/vFu5iq8gPQFByj4L0hkCEAJUR9I/>
>
> [3] https://eur02.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FX8-3pmioGxFZX3T0tRsdxPWKx3I%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579791237%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=a9%2F0dXk8nOb0YaoEOowtGP0b5M3%2BbXbbIe1vSxm4MJw%3D&reserved=0<https://
> mailarchive.ietf.org/arch/msg/tls/X8-3pmioGxFZX3T0tRsdxPWKx3I/>
>
> [4] https://eur02.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FZWTVxeh52P1LoJEHBJp_WTRsVBA%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579808542%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Pco5mFgulbpHQzoutWkjpynC4HGMgZg%2B8CAwsFvEJwM%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fssh%2F7KRZCX_bvZWUOG50HqDg_KVT77c%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579824396%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=QOC5qzHPaAAG97%2BwOCfAXL5JMnESbGAgpL5z93%2BwVgw%3D&reserved=0<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://
>> eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Ftools%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579840317%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=wQS00vHDKi64LyAzbh2oH2T01ob8N5voKYzA8TlULEw%3D&reserved=0 ).
>>
>>
>>
>>
>>
>>
>>
>> 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://
>> eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tls-
>> ecdhe-
>> mlkem%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579856163%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=IhwgbdmHVFXHR7qLuaDX3s3IdGmAt69GwM%2BLmc2zbuM%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fdoi.org%2F10.4444%2F100&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579872895%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=eHS0Tezga1%2BrQlrZHvY6IwNzOGEUZt1arZG3jRbZuRM%3D&reserved=0<https://
>> doi.org/10.4444/100>
>>
>>
>>
>> [1] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2F5lGA_ObJ5Z58PqIRyF8nC3Lj1Po%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579889437%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=LMbciwCivOdcZ9e6vRyypovp6joUleEVNYLzRoz%2BqTM%3D&reserved=0<https://
>> mailarchive.ietf.org/arch/msg/tls/5lGA_ObJ5Z58PqIRyF8nC3Lj1Po/>
>>
>> [2] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9958.html%23name-
>> post-quantum-and-
>> traditiona&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579905544%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=srXG9%2BY9bTpM3ns1FBUsQ6MT1SZqb68TkHUOq9EfAcg%3D&reserved=0<https://
>> www.rfc-editor.org/rfc/rfc9958.html#name-post-quantum-and-
>> traditiona>
>>
>> [3] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fgroups.google.com%2Fa%2Flist.nist.gov%2Fg%2Fpqc-
>>
>> forum%2Fc%2FWFRDl8DqYQ4%2Fm%2Fo2XJ2YvfAwAJ&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579921305%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=IT13tQaHWkm4%2BwZlf15nS4pzW0UoN1bYJkkOcDqrK%2BQ%3D&reserved=0<https://
>> groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/
>> o2XJ2YvfAwAJ>
>>
>> [4] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fnist.pqcrypto.org%2Ffoia%2Fhighlights.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579941294%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=W0xIuH8tAMAj2R4eid4mJcXm9yN6aBQai2X3zTjfyvs%3D&reserved=0<https://
>> nist.pqcrypto.org/foia/highlights.html>
>>
>> [5] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9958.html%23name-
>> hybrid-key-exchange-and-
>> sig&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579958098%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=6mukL7gQryi3EBBPEUgGJCVKmL6Rs3mR7NqCQIAVcdo%3D&reserved=0<https://
>> www.rfc-editor.org/rfc/rfc9958.html#name-hybrid-key-exchange-
>> and- sig>
>>
>> [6] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.openssh.org%2Ftxt%2Frelease-9.0&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649579979512%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=d9jKsYUO8xHp%2BfD5QCoRQTD4vPn0IqJRAvDwoZgCJWo%3D&reserved=0<https://
>> www.openssh.org/txt/release-9.0>
>>
>> [7] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.openssh.org%2Ftxt%2Frelease-10.4&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580001265%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=xcYOfl4tPgX%2B6TaTnvtgZg%2FmacaCN4aC0OG%2B9Zd6QW0%3D&reserved=0<https://
>> www.openssh.org/txt/release-10.4>
>>
>> [8] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.bsi.bund.de%2FSharedDocs%2FDownloads%2FEN%2FBSI%2FPublications%2FTechGuidelines%2FTG02102%2FBSI-
>>
>>
>>
>>
>>
>> TR-02102-2.pdf%3F__blob%3DpublicationFile%26v%3D11%23page%3D12&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580017496%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=rzlJ9ecTd2dOH4tMWCcgzoWtk0q%2BFfCFXRhnE%2FcNz8M%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.bsi.bund.de%2FSharedDocs%2FDownloads%2FEN%2FBSI%2FPublications%2FTechGuidelines%2FTG02102%2FBSI-
>>
>>
>>
>>
>>
>> TR-02102-1.pdf%3F__blob%3DpublicationFile%26v%3D14%23page%3D29&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580033518%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=ADie3XO5gArS6QGPxvnqOG9vHIs39cu82aA28Tq9ypY%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FhBFfH4lHo-
>>
>>
>>
>>
>>
>> cLPNfikGfxkoV6hAY%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580050032%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=hLfvUq3%2BjWrFgHjRmVJtv%2FjW336PZYjv81aSqkc%2BwMo%3D&reserved=0<https://
>> mailarchive.ietf.org/arch/msg/tls/hBFfH4lHo-cLPNfikGfxkoV6hAY/>
>>
>> [11] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FX44P3cF-
>> H4s8kX-
>> RzyZEeQYTkbo%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580066209%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=RcP%2FdIfRcQ2oBmeyJig79PdpZnV0jozFkPjXlH%2FqNDg%3D&reserved=0<https://
>> mailarchive.ietf.org/arch/msg/tls/X44P3cF-H4s8kX-RzyZEeQYTkbo/>
>>
>> [12] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.rfc-
>> editor.org%2Frfc%2Frfc3934.html%23section-2&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580082447%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=7v39MYpKORIAlsc9CVdNkol%2FlFuFjGZ4wIYbtqzrwas%3D&reserved=0<https://
>> www.rfc-editor.org/rfc/rfc3934.html#section-2>
>>
>> [13] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FxTiYQnK8uS181kRlFe7xiFjdD20%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580100512%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=TtNzwUooWdr5tVQhsj0y6L%2FKWzadT95NZyWDK13MgMo%3D&reserved=0<https://
>> mailarchive.ietf.org/arch/msg/tls/xTiYQnK8uS181kRlFe7xiFjdD20/>
>>
>> [14] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FLvUiinuyMPCXTFMrbeYB0aa1Iw4%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580116783%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=EhABSVEGl7anBhkt1GVNA%2FOgenkVK1iyE36D8ZV1QjU%3D&reserved=0<https://
>> mailarchive.ietf.org/arch/msg/tls/LvUiinuyMPCXTFMrbeYB0aa1Iw4/>
>>
>> [15] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.rfc-
>> editor.org%2Frfc%2Frfc3683.html%23section-1&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580132608%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=PCBoR61EYws40qNSIsvh%2Br7xt0RA6dReZQI4OrdxXoE%3D&reserved=0<https://
>> www.rfc-editor.org/rfc/rfc3683.html#section-1>
>>
>> [16] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fdatatracker.ietf.org%2Fperson%2FDeb%2520Cooley&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580148114<https://
>> datatracker.ietf.org/person/
>> Deb%20Cooley>%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=53pmRSDtsB7x0DMsCV3nkzwS1tYk9x4KzG%2B6aeS73S4%3D&reserved=0
>> "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://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.rfc-
>> editor.org%2Frfc%2Frfc9151.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580164198%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=M%2FnnPIcTCRiQymhjbpIxwYV7QrF9arK9Z6Ev%2B8FHPOk%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.rfc-
>> editor.org%2Frfc%2Frfc7776.html%23section-7&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580180610%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=NHmnC%2F9QvCRH%2F8CIZdotg%2B6rcGgPcnFyhCWrL8WvXYM%3D&reserved=0<https://
>> www.rfc-editor.org/rfc/rfc7776.html#section-7>
>>
>> [19] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20090117004931%2Fhttp%3A%2F%2Fwww.nsa.gov%2Fia%2Fprograms%2Fsuiteb_cryptography%2Findex.shtml&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580198516%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=4TE8ZJ6vY7c9DlshbapoCetaIzqkjx9isXB3mx2zSJE%3D&reserved=0<https://
>> web.archive.org/web/20090117004931/http://www.nsa.gov/ia/
>> programs/ suiteb_cryptography/index.shtml>
>>
>> [20] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fnvlpubs.nist.gov%2Fnistpubs%2FLegacy%2FSP%2Fnistspecialpublication800-56ar.pdf%23page%3D30&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580216521%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=91hqspPAqtWXxrsc%2BGzXAWesAIYFsxhphX%2Fu9C9WbOg%3D&reserved=0<https://
>> nvlpubs.nist.gov/nistpubs/Legacy/SP/
>> nistspecialpublication800-56ar.pdf#page=30>
>>
>> [21] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fcsrc.nist.gov%2Ffiles%2Fpubs%2Ffips%2F186-3%2Ffinal%2Fdocs%2Ffips_186-3.pdf%23page%3D101&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580232887%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=UEazxoOX%2FjTAnECxabS%2Fk8iu04p83yVxX7dkYDVpEHY%3D&reserved=0<https://
>> csrc.nist.gov/files/pubs/fips/186-3/final/docs/
>> fips_186-3.pdf#page=101>
>>
>> [22] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20090117004931%2Fhttp%3A%2F%2Fwww.nsa.gov%2Fia%2Fprograms%2Fsuiteb_cryptography%2Findex.shtml&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580251334%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=jEjJD099T7xg8XHd1uJtGj%2FzMq9ECGmLL6BFTqsN44U%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20150815072948%2Fhttps%3A%2F%2Fwww.nsa.gov%2Fia%2Fprograms%2Fsuiteb_cryptography%2Findex.shtml&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580269250%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=4Wvys4fJvga2fyQJ7mY0mt3Ig5sLKkH7UP78np6b37c%3D&reserved=0<https://
>> web.archive.org/web/20150815072948/https://www.nsa.gov/ia/
>> programs/ suiteb_cryptography/index.shtml>
>>
>> [24] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.rfc-
>> editor.org%2Frfc%2Frfc9151.html%23section-5.1&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580286109%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=M1gzvD9MCmNL0G3H5wcv6x1lF05qM%2BmdjWRAaqIoE2k%3D&reserved=0<https://
>> www.rfc-editor.org/rfc/rfc9151.html#section-5.1>
>>
>> [25] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.rfc-
>> editor.org%2Frfc%2Frfc9151.html%23section-8&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580302327%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=JdEqCGw9lcnuqqKs5jkoUtI2%2F66CcnV9P%2BEMW0RuVlI%3D&reserved=0<https://
>> www.rfc-editor.org/rfc/rfc9151.html#section-8>
>>
>> [26] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fwww.ietf.org%2Frfc%2Frfc8890.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580318335%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=JsPqvfLRFNDTMe5nf2mYHOyqG3aTFQsx50f9l%2BgZ%2B%2B0%3D&reserved=0<https://
>> www.ietf.org/rfc/rfc8890.html>
>>
>> [27] https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20260628050821%2Fhttps%3A%2F%2Fblog.cr.yp.to%2F20140323-
>>
>>
>>
>>
>>
>> ecdsa.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580334832%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=DRiU9OzTiPgifwIcXE0F53YjOYhRMJGQFzbQv95lKXw%3D&reserved=0<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://
>>> eur02.safelinks.protection.outlook.com/?
>>> url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20260425180701%2Fhttps%3A%2F%2Fwww.nsa.gov%2Fportals%2F75%2Fdocuments%2Fresources%2Feveryone%2Fcsfc%2Fthreat-
>>>
>>>
>>>
>>>
>>>
>>> prevention.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580351468%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=iU3FP8slwV%2BcYTVv8MGBwquXcjfJ90Qmfmhr9u%2F00ik%3D&reserved=0<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://
>>> eur02.safelinks.protection.outlook.com/?
>>> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspasm%2FytjNpbERE-
>>> YgKw-7c_w-
>>> ZRUA1Fw%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580368530%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=lXpaO%2Fw37sXcNStxC1ynIJt%2Fu22mewKLJel0EhWRA6Y%3D&reserved=0<https://
>>> mailarchive.ietf.org/arch/msg/spasm/ytjNpbERE-YgKw-7c_w-
>>> ZRUA1Fw/
>>>>
>>>
>>> The questions raised there remained unanswered: https://
>>> eur02.safelinks.protection.outlook.com/?
>>> url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspasm%2FWJMl6inph8t8m898kcBzhpWZC0o%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580385284%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=mGKyjpXpwfGnWjegNq2oQDEcacY5cEV4UA8SGZCUvfc%3D&reserved=0<https://
>>> mailarchive.ietf.org/arch/msg/spasm/
>>> WJMl6inph8t8m898kcBzhpWZC0o/
>>>>
>>>
>>> Kind regards,
>>>
>>> Ken Kubota
>>>
>>> ____________________________________________________
>>>
>>> Ken Kubota https://eur02.safelinks.protection.outlook.com/?
>>> url=https%3A%2F%2Fdoi.org%2F10.4444%2F100&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C057ef7380f594147771e08dedf3bbcd6%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639193649580403874%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=ooykX2bCl%2BPaiMA0SKggnNqwwyuhWmyDOlFODRv9H%2FY%3D&reserved=0<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]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]