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]
