Hi, We just found
Hi,Apologies for following up after my earlier approval - Douglas spotted one more issue.
In Section 2 OLD:Key establishment using NIST curves is outlined in Section 6.1.1.2 of [NIST-SP-800-56A].
NEW:Key establishment using NIST curves is outlined in Section 6.1.2.2 of [NIST-SP-800-56A].
My approval otherwise stands. Best, Kris On 7/30/26 11:23, Kris Kwiatkowski wrote:
Approved. Thank you all. On 7/30/26 03:16, Kampanakis, Panos wrote:Approved, thank you. -----Original Message-----From: Douglas Stebila<[email protected]> Sent: Wednesday, July 29, 2026 7:38 PMTo: Madison Church<[email protected]> Cc: Bas Westerbaan<[email protected]>; Kris Kwiatkowski<[email protected]>; Kampanakis, Panos<[email protected]>; Paul Wouters<[email protected]>; Bas Westerbaan<[email protected]>; Joseph Salowey<[email protected]>; RFC Editor<[email protected]>;[email protected];[email protected];[email protected];[email protected];[email protected] Subject: RE: [EXTERNAL] [AD] Final Review: RFC-to-be 10024 (draft-ietf-tls-ecdhe-mlkem) in XML CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. I approve. DouglasOn Jul 29, 2026, at 4:54 PM, Madison Church<[email protected]> wrote: Hi Bas, Thanks for the quick reply! We've made the requested updates and noted your approval here:https://queue.rfc-editor.org/final-review/rfc10024/. Updated files (please refresh): https://www.rfc-editor.org/authors/rfc10024.txt https://www.rfc-editor.org/authors/rfc10024.pdf https://www.rfc-editor.org/authors/rfc10024.html https://www.rfc-editor.org/authors/rfc10024.xml Updated diffs: https://www.rfc-editor.org/authors/rfc10024-diff.html https://www.rfc-editor.org/authors/rfc10024-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc10024-auth48diff.html https://www.rfc-editor.org/authors/rfc10024-auth48rfcdiff.html (side by side) We will assume your assent to any further changes submitted by your coauthors unless we hear objection at that time. We will await approvals from each of the parties listed at the Final Review status page prior to moving this document forward in the publication process. Thank you! Madison Church RFC Production CenterOn Jul 29, 2026, at 3:38 PM, Bas Westerbaan<[email protected]> wrote:On 29 Jul 2026, at 22:09, Madison Church<[email protected]> wrote: Bas, Kris, *Paul, *Paul - As delegated AD for this document, please review and approve the following updates (which can be viewed in this diff file:https://auth48-transition.rfc-editor.org/authors/rfc10024-auth48diff.html). - Added text to Section 6 (Security Considerations) - [NIST-SP-800-56A] reference moved from the Normative References section to the Informative References section Bas, Kris - Thank you for your replies! We have updated the document accordingly and just have 2 followup items for your review. 1) We have updated [DUALECTLS] according to our new Reference Style Guidance available on authors.ietf.org<http://authors.ietf.org/> (seehttps://authors.ietf.org/en/reference-style-guidance#conference-papers) to include the conference name and the authors of this paper. Current: [DUALECTLS] Checkoway, S., Fredrikson, M., Niederhagen, R., Everspaugh, A., Green, M., Lange, T., Ristenpart, T., Bernstein, D., Maskiewicz, J., and H. Shacham, "On the Practical Exploitability of Dual EC in TLS Implementations", 23rd USENIX Security Symposium (USENIX Security 14), 2014,<https://www.usenix.org/system/files/conference/ usenixsecurity14/sec14-paper-checkoway.pdf>.Looks good. If you allow multiple initials, then I’d use “Bernstein, D. J.,” instead of “Bernstein, D.” here.2) We’ve updated the Security Considerations section per your replies.I spotted a typo. OLD: In contrast, the ECDHE ephemeral scalars taken from the RNG are never NEW: In contrast, the ECDH ephemeral scalars taken from the RNG are neverPlease review this section carefully to ensure we’ve captured everything correctly. In addition, we have slightly modified the last sentence to 1) use the correct form of "affect" (verb) vs. "effect" (noun), and 2) reduce the slight repetition of the phrase "as well" at the end of the last two sentences in this section. Let us know if there are any objections. Current: If the same insecure RNG is used by both algorithms, then a disclosure of state by one of the algorithms will also affect the security of the other algorithm.Looks good.Authors - Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process.With the typo corrected, I approve. Thank you! Best, BasThe files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc10024.txt https://www.rfc-editor.org/authors/rfc10024.pdf https://www.rfc-editor.org/authors/rfc10024.html https://www.rfc-editor.org/authors/rfc10024.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc10024-diff.html https://www.rfc-editor.org/authors/rfc10024-rfcdiff.html (side by side)https://www.rfc-editor.org/authors/rfc10024-auth48diff.html https://www.rfc-editor.org/authors/rfc10024-auth48rfcdiff.html (side by side) For the Final Review status page, please see: https://queue.rfc-editor.org/final-review/rfc10024/ Thank you! Madison Church RFC Production CenterOn Jul 29, 2026, at 12:48 AM, Kris Kwiatkowski<[email protected]> wrote: (Sending again for improved readability) Dear Madison, Co-authors, all After reading the text I've found few editorial defects In 8.1 OLD: [NIST-SP-800-227] Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A., Silberg, H., and N. Waller, "Recommendations for Key- Ecapsulation Mechanisms", National Institute of Standards NEW: [NIST-SP-800-227] Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A., Silberg, H., and N. Waller, "Recommendations for Key- Encapsulation Mechanisms", National Institute of Standards (typo: there is missing 'n' in Encapsulation) In 4.2 OLD: bytes for the ML-KEM part and 97 bytes for secp384r1) NEW: bytes for the ML-KEM part and 97 bytes for secp384r1). (typo: final '.' is missing). In 4.3 OLD: the concatenation of the ECDHE and ML-KEM shared secret NEW: the concatenation of the ECDHE and ML-KEM shared secrets? (typo: shouldn't secret be plural?) In 6. Please add following text at the end of the section: "If the same insecure RNG is used by both algorithms then a disclosure of state by one of the algorithms will effect the security of the other algorithm as well." It was committed here, at a later stage: https://github.com/tlswg/tls-ecdhe-mlkem/pull/71 In 8.1 I believe [NIST-SP-800-56A] should be moved from normative to informative references. It is only cited in 2. and informatively. Otherwise, the document looks great (taking into account recent feedback from Bas). Cheers, Kris On 7/28/26 23:53, Joseph Salowey wrote:You might need to use dark mode to see Kris' edits (for me, the text is white on a white background). Also for the text in 6 - "If the same insecure RNG is used by both algorithms then a disclosure of state by one of the algorithms will affect the security of the other algorithm as well." This text was submitted as an individual, without a chair hat on. Feel free to omit it if you think it's getting in the weeds. Joe On Tue, Jul 28, 2026 at 3:39 PM Kris Kwiatkowski<[email protected]> wrote:Dear Madison, Co-authors, all After reading the text I've found few editorial defects In 8.1 OLD: [NIST-SP-800-227] Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A., Silberg, H., and N. Waller, "Recommendations for Key- Ecapsulation Mechanisms", National Institute of Standards NEW: [NIST-SP-800-227] Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A., Silberg, H., and N. Waller, "Recommendations for Key- Encapsulation Mechanisms", National Institute of Standards (typo: there is missing 'n' in Encapsulation) In 4.2 OLD: bytes for the ML-KEM part and 97 bytes for secp384r1) NEW: bytes for the ML-KEM part and 97 bytes for secp384r1). (typo: final '.' is missing). In 4.3 OLD: the concatenation of the ECDHE and ML-KEM shared secret NEW: the concatenation of the ECDHE and ML-KEM shared secrets? (typo: shouldn't secret be plural?) In 6. Please add following text at the end of the section: "If the same insecure RNG is used by both algorithms then a disclosure of state by one of the algorithms will effect the security of the other algorithm as well." It was committed here, at a later stage: https://github.com/tlswg/tls-ecdhe-mlkem/pull/71 In 8.1 I believe [NIST-SP-800-56A] should be moved from normative to informative references. It is only cited in 2. and informatively. Otherwise, the document looks great (taking into account recent feedback from Bas). Cheers, Kris On 7/28/26 19:01, Bas Westerbaan wrote: Hi Madison, Thanks for the quick edits. On 28 Jul 2026, at 19:19, Madison Church<[email protected]> wrote: Hi Authors, Thank you for your responses! We have updated the document accordingly and have 5 followup items for your review (we’ve tried to consolidate updates per everyone’s responses here, but please let us know if we’ve missed something). Updated files have been posted below in this thread. Edits looks good. But on reading I see now that we shouldn’t use ECDHE instead of ECDH in one spot: the IANA Considerations (Section 7). OLD: Comment: Combining X25519 ECDHE with ML-KEM-768 NEW: Comment: Combining X25519 ECDH with ML-KEM-768 OLD: Comment: Combining secp384r1 ECDHE with ML-KEM-1024 NEW: Comment: Combining secp384r1 ECDH with ML-KEM-1024 OLD: Comment: Combining secp256r1 ECDHE with ML-KEM-768 NEW: Comment: Combining secp256r1 ECDH with ML-KEM-768 Also I spotted an old typo in Douglas’ e-mail address. OLD: [email protected] NEW: [email protected] 1) For the following (from Deb): Please note that some of the text that was agreed during wglc for draft-ietf-tls-mlkem need to be added to this draft as well (specifically the randomizer text, when it applies to this draft). Authors - Can you point us to the final text that should be added to the document (and where the text should be placed)? We note that this pull request (https://github.com/tlswg/tls-ecdhe-mlkem/pull/69) has been merged, but we want to make sure we incorporate the correct text. Section 6 (Security Considerations) OLD: All groups defined in this document use and generate fixed-length public keys, ciphertexts, and shared secrets, which complies with the requirements described in Section 6 of [RFC9954]. NEW: All groups defined in this document use and generate fixed-length public keys, ciphertexts, and shared secrets, which complies with the requirements described in Section 6 of [RFC9954]. During ML-KEM encapsulation, encapsulation randomness <tt>m</tt> is drawn from a random bit generator and encrypted (see [NIST-FIPS-203], Algorithms 17 and 20); the client, which holds the decapsulation key, then recovers <tt>m</tt> exactly during decapsulation (see [NIST-FIPS-203], Algorithm 18). Consequently, any information <tt>m</tt> carries about the generator's other outputs is also exposed to the client. The disclosure of the output(s) of an insecure random number generator (RNG) when used in TLS can be used in an attack to compromise the state of the insecure RNG itself as described in [DUALECTLS]. The encapsulation randomness <tt>m</tt> in ML-KEM is an additional place where RNG output is disclosed to an active attacker. Implementers should follow the RBG guidance in [NIST-FIPS-203] and the random number generation guidance in Appendix C.1 of [RFC9846]. Implementers can choose to implement mechanisms from [RFC8937] for additional protection across sessions. In contrast, the ECDHE ephemeral scalars taken from the RNG are never directly disclosed to the peer. However, any passive observer with access to a cryptographically relevant quantum computer (CRQC) can recover the scalar, which is derived directly from RNG output. Regardless, ephemeral scalars should always be generated using a cryptographically secure RNG: for secp256r1 and secp384r1 as required by [NIST-SP-800-56A], and for X25519 as described in [RFC7748]; the guidance in Appendix C.1 of [RFC9846] applies here as well. Section 8.2 (Informative References) Please add the following two references (cited by the new Section 6 text above): NEW: [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., and C. Wood, "Randomness Improvements for Security Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, <https://www.rfc-editor.org/rfc/rfc8937>. [DUALECTLS] "On the Practical Exploitability of Dual EC in TLS Implementations", 2014,<https://www.usenix.org/system/files/conference/ usenixsecurity14/sec14-paper-checkoway.pdf>.Section 1 (Introduction) OLD: ML-KEM is a key encapsulation mechanism (KEM) defined in the [NIST-FIPS-203]. NEW: ML-KEM is a key encapsulation mechanism (KEM) defined in [NIST-FIPS-203]. Section 4.2 (Server Share) OLD: The size of the server share is 1665 bytes (1568 bytes for the ML-KEM part and 97 bytes for secp384r1) NEW: The size of the server share is 1665 bytes (1568 bytes for the ML-KEM part and 97 bytes for secp384r1). 2) We have updated with your proposed title with further improvements per Panos’ suggestion regarding the use of "post-quantum hybrid" (see #4 below). Please let us know any objections. Current (Title): Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 Current (Abbreviated Title): PQ/T Hybrids for TLS 1.3 Looks good to me. 3) For consistency throughout the document, we have updated each instance of "Elliptic Curve Diffie-Hellman" and "ECDH" to "Ephemeral Elliptic Curve Diffie-Hellman" and "ECDHE", respectively. Please review and let us know any objections. Additionally, should the keyword "ECDH" be updated to "ECDHE"? Perhaps both like RFC 10015? 4) Per Panos’ suggestion, we have updated to use "PQ/T" in the document after the expansion "Post-Quantum Traditional" to align with RFC 9794. Let us know if you prefer otherwise. Looks good. 5) Would adding a citation for RFC 9794 after "Post-Quantum Traditional (PQ/T) hybrid key agreements" work here? Current: This document introduces three new supported groups for Post-Quantum Traditional (PQ/T) hybrid key agreements in TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine ML-KEM with Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) in the manner described in [RFC9954]. Perhaps: This document introduces three new supported groups for Post-Quantum Traditional (PQ/T) hybrid key agreements [RFC9794] in TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine ML-KEM with Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) in the manner described in [RFC9954]. Yes. Thanks, Bas
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
