In this message, I am responding collectively to the following emails:
- William Layton (NSA)
- Deb Cooley (Sec AD)
Due to the high volume of traffic from this mailing list, I will create a new
email address.
I would like to mention this in advance to avoid any misunderstandings, as the
new email address will be registered before the current one is removed.
William Layton (NSA):
On Tue, 07 July 2026 [1]:
> The two independent layers is all about implementation, not cryptography. If
> you look at the more detailed solutions that implement two layers you'll see
> separate boxes with firewalls, intrusion detection, etc. placed between them.
> That concept is orthogonal to a discussion of multiple algorithms.
My question was:
> > Why the apparent change of position?
> > In this PDF document, the NSA consistently requires the exact opposite: a
> > hybrid approach (two tunnels/layers).
1. The concept of a (parallel) hybrid approach is to safeguard against failure
of a single component. Whether the hybrid approach is applied across
implementation boundaries or across cryptographic algorithms is irrelevant to
the nature of the hybrid approach.
In this case, it safeguards against any (future) compromise of ML-KEM (or
weaknesses associated with it) by also using ECC.
Therefore, the distinction between implementation and cryptography is
irrelevant in this context.
2. Post-quantum algorithms are immature. RFC 9958 (Post-Quantum Cryptography
for Engineers) [2] from June 2026: "the post-quantum algorithms face
uncertainty about the underlying mathematics, compliance issues, unknown
vulnerabilities, and hardware and software implementations that have not had
sufficient maturing time to rule out traditional cryptanalytic attacks and
implementation bugs."
ECC was far better understood and studied at the time it was standardized.
I myself found it surprising how quickly the NIST PQC standardization process
took place. The subsequent cryptanalytic breaks of several algorithms,
including a finalist, are therefore less surprising.
3. SIKE, a NIST finalist, was shown to be breakable in 2022, only four years
ago. Under these circumstances, cutting away the second safety belt introduces
unnecessary risk.
4. Moreover, contrary to the explicit recommendation of one of the authors of
ML-KEM/Kyber (Peter Schwabe), the hash was removed even though it would help
protect against attacks such as the NSA's Dual_EC_DRBG backdoor, which NIST was
ultimately forced to remove: "Should those RNGs include the hash? Yes, of
course. [...] Of course, as you stated in a another message, the RNG output may
leak through all kind of other sources, but the hash in Kyber's Ecnaps is a
cheap "defense-in-depth" mechanism to ensure that we don't add another source
of leakage." [3]
As the Kyber author mentions correctly, adding the hash is inexpensive, and
removing it without a compelling justification raises legitimate concerns.
Given that the NSA's contribution was never disclosed ("The FOIA results show
that what NIST publicly labeled as the "Post Quantum Cryptography Team,
National Institute of Standards and Technology (NIST), [email protected]" actually
had more NSA members than NIST members." [4]), these circumstances warrant
careful scrutiny.
5. Anything other than using a hybrid approach here is difficult to justify
from a cryptographic perspective.
This is especially true given the risks outlined above.
For these reasons, the hybrid approach is explicitly recommended in RFC 9958
(Post-Quantum Cryptography for Engineers) Section 15.4. [5]: "Hybrid key
exchange is recommended to enhance security against the HNDL attack.
Additionally, hybrid signatures provide for time to react in the case of the
announcement of a devastating attack against any one algorithm, while not fully
abandoning traditional cryptosystems."
6. Virtually everyone else has also chosen a hybrid approach.
Not only did OpenSSH adopt a hybrid approach by default in 2022 ("use the
hybrid Streamlined NTRU Prime + x25519 key exchange method by default
("[email protected]")" [6]), but it also adopted another
hybrid scheme only a few days ago ("OpenSSH 10.4 was released on 2026-07-06.
[...] add experimental support for a composite post-quantum signature scheme
that combines ML-DSA 44 and Ed25519" [7]).
Germany's NIST counterpart, the BSI, reaches the same conclusion. Technical
Guideline TR-02102-2 (version 2026-01): "The BSI intends to recommend the
quantum-safe hybrid key agreement mechanisms SecP256r1MLKEM768 and
SecP384r1MLKEM1024 from the Internet-Draft at
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ as soon as the
corresponding RFC has been adopted." [8]
BSI TR-02102-1 (version 2026-01): "The quantum-safe mechanisms recommended in
this Technical Guideline are generally not yet trusted to the same extent as
the established classical mechanisms, since they have not been as well studied
with regard to side-channel resistance and implementation security. To ensure
the long-term security of a key agreement, this Technical Guideline therefore
recommends the use of a hybrid key agreement mechanism that combines a
quantum-safe and a classical mechanism. An obvious hybridization is to perform
two key agreements in parallel and to derive a combined key from the generated
key material." [9]
There are multiple significant warning signs.
I can only respond intermittently, and lack of response, even for a longer
time, does not mean endorsement. Currently, my resources are outmatched by
those of the NSA.
Deb Cooley (Sec AD):
On Tue, 07 July 2026 15:55 UTC [10]:
> This is a public warning to the entire TLS working group, in accordance with
> RFC 3934 Section 2 [0].
[...]
> *not participating in ad hominum attacks (veiled or unveiled)
> *not sending multiple responses in quick succession
On Tue, 07 July 2026 17:37 UTC [11]:
> I will only engage on a couple of points:
>
> 1. Obviously those participants who have been contributing in good faith have
> nothing to worry about.
>
> 2. The new participants should read the rules prior to posting, this warning
> will help them understand what is expected.
RFC 3934 Section 2 [12] explicitly states that a public warning is the second
step after communicating directly with the offending individual:
"Unless the disruptive behavior is severe enough that it must be stopped
immediately, the WG chair should attempt to discourage the disruptive behavior
by communicating directly with the offending individual. If the behavior
persists, the WG chair should send at least one public warning on the WG
mailing list."
I feel it necessary to seek clarification, since the warning and the subsequent
email referring to "[t]he new participants" (plural) were issued shortly after
I entered the mailing list and someone accused me of an ad hominem attack,
although my point clearly concerned a potential conflict of interest related to
NSA activity on this mailing list, and, in that context, specific actions (or
failures to act) by NSA employees [13].
Andrew Lee made a point [14] with which I agree and which I would rephrase as
follows: an indiscriminate warning can have an intimidating effect and
therefore is detrimental to an open discussion.
The same holds for any vagueness in the interpretation of rules.
He also wrote:
> > *not sending multiple responses in quick succession
>
> Participants on both sides have posted multiple messages throughout this
> WGLC. This standard has never previously been cited or enforced. Further,
> this warning starves debate during a WGLC; whether that's intentional or not
> doesn't matter.
To avoid intimidation and ensure the fair application of the rules, all parties
should strictly adhere to the RFCs and avoid any uncertainty caused by vague
wording.
My understanding is the following:
1. RFC 3934 Section 2 states that, in the case of disruptive behavior, the WG
(working group) chair should first contact the individual directly. Ideally,
the relevant passage should be quoted and the reason explained.
2. RFC 3934 Section 2 states that a public warning should be issued by the WG
chair only as a second step, and the wording implies that the individual should
be identified in the public warning (and also not to intimidate others).
3. RFC 3934 Section 2 states that neither individual correspondence nor a
public warning should be conducted by the AD (Area Director), but by the WG
chair.
4. RFC 3934 Section 2 does not state that "new participants" should be greeted
with a warning message.
5. The term "contributing in good faith" is subject to interpretation, and in
order to avoid intimidation, any person to be warned should be mentioned by
name instead. For example, not only many researchers, but probably the majority
of the world population would reasonably question whether the pervasive NSA
presence in this working group qualifies as "contributing in good faith."
6. Discussions about conflict of interest related to the NSA, including their
behavior on this mailing list with regard to a potential conflict of interest -
as NSA employees, not as members of a specific ethnicity or some other outward
property - constitute neither an ad hominem attack nor some other violation of
any rule.
7. The criterion "not sending multiple responses in quick succession" is not
part of any RFC, as the RFCs define criteria based on content rather than
frequency (e.g., RFC 3683 Section 1 [15] mentions "unsolicited bulk e-mail" or
"discussion of subjects unrelated to IETF policy" etc.). (If a numerical
criterion is unavoidable, it should be exactly defined, e.g., more than two
emails per hour.) I find such a vague formulation problematic, as I sometimes
edit several emails in parallel, and later send them at the same time, which
would formally satisfy the criterion "sending multiple responses in quick
succession" although my overall email volume is no higher than that of others.
8. An AD (Area Director) who has retired from the NSA after 35+ years no less
than three years ago [16] and published RFC 9151 in 2022 as an NSA employee
[17] would present a conflict of interest when dealing with questions
concerning the NSA, including whether a debate constitutes a legitimate
discussion of a conflict of interest related to the NSA. In such a case, that
AD should therefore recuse themselves in accordance with RFC 7776 Section 7
(Conflicts of Interest) [18]: "Furthermore, a conflict of interest arises if
the person involved in the process of handling a harassment report is closely
associated personally or through affiliation with any of the Reporter,
Respondent, or Subject. / For the avoidance of doubt, recusal in this context
means completely stepping out of any advisory or decision-making part of any
process associated with handling a harassment report, remedy arising from a
harassment report, or appeal into the handling of a harassment report. That
means that a recused person has no more right to participate in or witness the
process than any other person from the community in the same situation." One
example of a potential conflict of interest is the publication of an RFC
authored solely by an NSA employee [17]. When NSA announced Suite B
Cryptography in 2005 and published the corresponding webpage in 2009 [19], the
obvious strategy was to make the security levels of 128 bits of security (e.g.,
curve P-256) and 192 bits of security (e.g., curve P-384) publicly available as
Suite B, but withhold the security level of 256 bits of security (e.g., curve
P-521) as part of Suite A [19, 20, 21]. (From the beginning, only AES-256 was
used to "to enhance interoperability" [22], and in August 2015, the security
level of 128 bits of security was removed [23].) This may explain why RFC 9151
Section 5.1 [24] lists only curve P-384 (192 bits of security) as the sole
acceptable curve without providing a rationale in Section 8 (Security
Considerations) [25] for this limitation. While providing a minimum security (a
lower bound) for commercial applications is a legitimate concern, establishing
a limitation (an upper bound) by withholding 256 bits of security is not. RFC
8890 clearly says "The Internet is for End Users" [26], and this means strong
cryptography (256 bits of security) should be available for everyone. Notably,
Bernstein explicitly praises curve P-521 (256 bits of security): "To be fair I
should mention that there's one standard NIST curve using a nice prime, namely
2^521−1" [27].
Please confirm this understanding or, if you disagree, provide an explanation
or clarification.
It would be helpful if every email received from the mailing list included a
permanent archive link in its signature, so that participants do not have to
search the archives manually when quoting previous messages.
Kind regards,
Ken Kubota
____________________________________________________
Ken Kubota
https://doi.org/10.4444/100
[1] https://mailarchive.ietf.org/arch/msg/tls/5lGA_ObJ5Z58PqIRyF8nC3Lj1Po/
[2] https://www.rfc-editor.org/rfc/rfc9958.html#name-post-quantum-and-traditiona
[3]
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/o2XJ2YvfAwAJ
[4] https://nist.pqcrypto.org/foia/highlights.html
[5] https://www.rfc-editor.org/rfc/rfc9958.html#name-hybrid-key-exchange-and-sig
[6] https://www.openssh.org/txt/release-9.0
[7] https://www.openssh.org/txt/release-10.4
[8]
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=11#page=12
[9]
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile&v=14#page=29
[10] https://mailarchive.ietf.org/arch/msg/tls/hBFfH4lHo-cLPNfikGfxkoV6hAY/
[11] https://mailarchive.ietf.org/arch/msg/tls/X44P3cF-H4s8kX-RzyZEeQYTkbo/
[12] https://www.rfc-editor.org/rfc/rfc3934.html#section-2
[13] https://mailarchive.ietf.org/arch/msg/tls/xTiYQnK8uS181kRlFe7xiFjdD20/
[14] https://mailarchive.ietf.org/arch/msg/tls/LvUiinuyMPCXTFMrbeYB0aa1Iw4/
[15] https://www.rfc-editor.org/rfc/rfc3683.html#section-1
[16] https://datatracker.ietf.org/person/Deb%20Cooley
"Deb Cooley
Pronouns: she/her
Retired Senior Cryptographic Vulnerability Analyst, National Security Agency
Cybersecurity Directorate (NSA/CSD) with 37+ years of service in Dec 2023. Most
of Deb’s career was spent as a security evaluator on many different
technologies including IP encryptors, satellites, radios, and key management
devices.
Previously, Special Government Expert for the Department of Homeland Security,
Cybersecurity and Infrastructure Security Agency’s Cyber Security Division.
Previously, acme working group chair."
[17] https://www.rfc-editor.org/rfc/rfc9151.html
"Published: April 2022
Author: D. Cooley
NSA"
"Author's Address
Dorothy Cooley
National Security Agency
Email: [email protected]"
[18] https://www.rfc-editor.org/rfc/rfc7776.html#section-7
[19]
https://web.archive.org/web/20090117004931/http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
[20]
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-56ar.pdf#page=30
[21]
https://csrc.nist.gov/files/pubs/fips/186-3/final/docs/fips_186-3.pdf#page=101
[22]
https://web.archive.org/web/20090117004931/http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
"1. CNSSP-15 correctly states that 192-bit AES keys are sufficient for
protecting even TOP SECRET information. However, Suite B uses only 256-bit keys
to enhance interoperability."
[23]
https://web.archive.org/web/20150815072948/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
[24] https://www.rfc-editor.org/rfc/rfc9151.html#section-5.1
[25] https://www.rfc-editor.org/rfc/rfc9151.html#section-8
[26] https://www.ietf.org/rfc/rfc8890.html
[27]
https://web.archive.org/web/20260628050821/https://blog.cr.yp.to/20140323-ecdsa.html
> Am 07.07.2026 um 23:54 schrieb [email protected]
> <[email protected]>:
>
> The two independent layers is all about implementation, not cryptography. If
> you look at the more detailed solutions that implement two layers you'll see
> separate boxes with firewalls, intrusion detection, etc. placed between
> them. That concept is orthogonal to a discussion of multiple algorithms.
>
> Get Outlook for Android
>
> From: Ken Kubota <[email protected]>
> Sent: Tuesday, July 7, 2026 5:47:51 PM
> To: William Layton (GOV) <[email protected]>
> Cc: [email protected] <[email protected]>
> Subject: Re: [TLS] WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
>
> Why the apparent change of position?
>
> In this PDF document, the NSA consistently requires the exact opposite: a
> hybrid approach (two tunnels/layers).
>
> "The security against a passive attack targeting Data in Transit
> (DiT) across Public Black networks is provided by the layered
> encryption of two independent tunnels (Inner and Outer)
> using a specific selection of security protocols as instructed
> in each CP. The two independent Encryption Components
> provide confidentiality and high-level assurance for the
> solution, because the adversary should never be able to
> exploit a single cryptographic implementation to
> compromise both tunnels.
>
> Two layers of Data at Rest (DAR) Commercial National Security
> Algorithm (CNSA) encryption are employed to provide
> confidentiality and mitigate passive attacks of stored data.
> The DAR components are independent in a number of ways
> to mitigate the ability of an adversary to exploit a single
> cryptographic implementation to compromise both layers."
>
> This document is available at:
> https://web.archive.org/web/20260425180701/https://www.nsa.gov/portals/75/documents/resources/everyone/csfc/threat-prevention.pdf
>
> It is also still available on the NSA website.
>
> Originally referenced in:
> https://mailarchive.ietf.org/arch/msg/spasm/ytjNpbERE-YgKw-7c_w-ZRUA1Fw/
>
> The questions raised there remained unanswered:
> https://mailarchive.ietf.org/arch/msg/spasm/WJMl6inph8t8m898kcBzhpWZC0o/
>
> Kind regards,
>
> Ken Kubota
>
> ____________________________________________________
>
> Ken Kubota
> https://doi.org/10.4444/100
>
>
>
> Am 07.07.2026 um 22:08 schrieb [email protected]
> <[email protected]>:
>
> I support publication.
> Implementors will make their own decisions. This algorithm choice looks
> likely to be implemented in multiple places, so having clear documentation of
> both security considerations and technical details (as provided by the draft)
> is worthwhile for those who might choose to use it.
>
> -Bill
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
