> 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]
