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]
