rfc9954v2.txt   rfc9954.txt 
skipping to change at line 387 skipping to change at line 387
For a hybrid key exchange, the key_exchange field of a KeyShareEntry For a hybrid key exchange, the key_exchange field of a KeyShareEntry
is the concatenation of the key_exchange field for each of the is the concatenation of the key_exchange field for each of the
constituent algorithms. The order of shares in the concatenation constituent algorithms. The order of shares in the concatenation
MUST be the same as the order of algorithms indicated in the MUST be the same as the order of algorithms indicated in the
definition of the NamedGroup. definition of the NamedGroup.
For the client's share, the key_exchange value contains the For the client's share, the key_exchange value contains the
concatenation of the pk outputs of the corresponding KEMs' KeyGen concatenation of the pk outputs of the corresponding KEMs' KeyGen
algorithms if that algorithm corresponds to a KEM or the (EC)DH algorithms if that algorithm corresponds to a KEM or the (EC)DH
ephemeral key share if that algorithm corresponds to an (EC)DH group. ephemeral key share if that algorithm corresponds to an (EC)DH group.
For the server's share, the key_exchange value contains concatenation For the server's share, the key_exchange value contains the
of the ct outputs of the corresponding KEMs' Encaps algorithms if concatenation of the ct outputs of the corresponding KEMs' Encaps
that algorithm corresponds to a KEM or the (EC)DH ephemeral key share algorithms if that algorithm corresponds to a KEM or the (EC)DH
if that algorithm corresponds to an (EC)DH group. ephemeral key share if that algorithm corresponds to an (EC)DH group.
Section 4.2.8 of [TLS13] requires that "The key_exchange values for Section 4.2.8 of [TLS13] requires that "The key_exchange values for
each KeyShareEntry MUST be generated independently." In the context each KeyShareEntry MUST be generated independently." In the context
of this document, the same algorithm may appear in multiple named of this document, the same algorithm may appear in multiple named
groups; thus, this document relaxes the above requirement to allow groups; thus, this document relaxes the above requirement to allow
the same key_exchange value for the same algorithm to be reused in the same key_exchange value for the same algorithm to be reused in
multiple KeyShareEntry records sent within the same ClientHello. multiple KeyShareEntry records sent within the same ClientHello.
However, key_exchange values for different algorithms MUST be However, key_exchange values for different algorithms MUST be
generated independently. Explicitly, if the NamedGroup is the hybrid generated independently. Explicitly, if the NamedGroup is the hybrid
key exchange MyECDHMyPQKEM, the KeyShareEntry.key_exchange values key exchange MyECDHMyPQKEM, the KeyShareEntry.key_exchange values
skipping to change at line 451 skipping to change at line 451
}, },
} }
3.3. Shared Secret Calculation 3.3. Shared Secret Calculation
This document also takes a simple "concatenation approach" for the This document also takes a simple "concatenation approach" for the
calculation of shared secrets: The two shared secrets are calculation of shared secrets: The two shared secrets are
concatenated together and used as the shared secret in the existing concatenated together and used as the shared secret in the existing
TLS 1.3 key schedule. Again, this document does not add any TLS 1.3 key schedule. Again, this document does not add any
additional structure (length fields) in the concatenation procedure; additional structure (length fields) in the concatenation procedure;
for both the traditional groups and post quantum KEMs, the shared for both the traditional groups and post-quantum KEMs, the shared
secret output length is fixed for a specific elliptic curve or secret output length is fixed for a specific elliptic curve or
parameter set. parameter set.
In other words, if the NamedGroup is MyECDHMyPQKEM, the shared secret In other words, if the NamedGroup is MyECDHMyPQKEM, the shared secret
is calculated as: is calculated as:
concatenated_shared_secret = MyECDH.shared_secret concatenated_shared_secret = MyECDH.shared_secret
|| MyPQKEM.shared_secret || MyPQKEM.shared_secret
and inserted into the TLS 1.3 key schedule in place of the (EC)DHE and inserted into the TLS 1.3 key schedule in place of the (EC)DHE
skipping to change at line 622 skipping to change at line 622
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 9846, DOI 10.17487/RFC9846, April 2026,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc9846>.
7.2. Informative References 7.2. Informative References
[AVIRAM] Nimrod Aviram, Benjamin Dowling, Ilan Komargodski, Kenny [AVIRAM] Nimrod Aviram, Benjamin Dowling, Ilan Komargodski, Kenny
Paterson, Eyal Ronen, and Eylon Yogev, "[TLS] Combining Paterson, Eyal Ronen, and Eylon Yogev, "[TLS] Combining
Secrets in Hybrid Key Exchange in TLS 1.3", 1 September Secrets in Hybrid Key Exchange in TLS 1.3", 1 September
2021, <https://mailarchive.ietf.org/arch/msg/tls/ 2021, <https://mailarchive.ietf.org/arch/msg/tls/
F4SVeL2xbGPaPB2GW_GkBbD_a5M/>. F4SVeL2xbGPaPB2GW_GkBbD_a5M/>.
[BCNS15] Bos, J., Costello, C., Naehrig, M., and D. Stebila, "Post- [BCNS15] Bos, J., Costello, C., Naehrig, M., and D. Stebila, "Post-
skipping to change at line 695 skipping to change at line 695
[ECDHE-MLKEM] [ECDHE-MLKEM]
Kwiatkowski, K., Kampanakis, P., Westerbaan, B., and D. Kwiatkowski, K., Kampanakis, P., Westerbaan, B., and D.
Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement
for TLSv1.3", Work in Progress, Internet-Draft, draft- for TLSv1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-ecdhe-mlkem-04, 8 February 2026, ietf-tls-ecdhe-mlkem-04, 8 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls- <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
ecdhe-mlkem-04>. ecdhe-mlkem-04>.
[ETSI] Campagna, M., Ed., et al., "Quantum Safe Cryptography and [ETSI] Campagna, M., Ed., et al., "Quantum Safe Cryptography and
Security: An introduction, benefits, enablers and Security: An introduction, benefits, enablers and
challengers", ETSI White Paper No. 8, June 2015, challenges", ETSI White Paper No. 8, June 2015,
<https://www.etsi.org/images/files/ETSIWhitePapers/ <https://www.etsi.org/images/files/ETSIWhitePapers/
QuantumSafeWhitepaper.pdf>. QuantumSafeWhitepaper.pdf>.
[EVEN] Even, S. and O. Goldreich, "On the Power of Cascade [EVEN] Even, S. and O. Goldreich, "On the Power of Cascade
Ciphers", Advances in Cryptology, pp. 43-50, Ciphers", Advances in Cryptology, pp. 43-50,
DOI 10.1007/978-1-4684-4730-9_4, 1984, DOI 10.1007/978-1-4684-4730-9_4, 1984,
<https://doi.org/10.1007/978-1-4684-4730-9_4>. <https://doi.org/10.1007/978-1-4684-4730-9_4>.
[EXTERN-PSK] [EXTERN-PSK]
Housley, R., "TLS 1.3 Extension for Certificate-Based Housley, R., "TLS 1.3 Extension for Certificate-Based
 End of changes. 4 change blocks. 
8 lines changed or deleted 8 lines changed or added

This html diff was produced by rfcdiff 1.48.