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 Center > On 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/> (see >> https://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 never > > >> Please 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, > > Bas > >> >> The 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 Center >> >> >>> On 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]
