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
