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]
