I approve. Douglas
> On 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 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]
