Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] Note that we have updated the short title, which appears in the running header in the PDF output, as follows. Original: ietf-tls-hybrid-design Current: Hybrid Key Exchange in TLS 1.3 --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!-- [rfced] How may we clarify "negotiated and transmitted" in this sentence? Are these part of a series (i.e., viewed, negotiated, and transmitted) as shown in Perhaps A, or should this phrase be revised as shown in Perhaps B? Original: each hybrid key exchange combination should be viewed as a single new key exchange method, negotiated and transmitted using the existing TLS 1.3 mechanisms. Perhaps A: Each hybrid key exchange combination should be viewed as a single new key exchange method, negotiated, and transmitted using the existing TLS 1.3 mechanisms. Perhaps B: Each hybrid key exchange combination should be viewed as a single new key exchange method that should be negotiated and transmitted using the existing TLS 1.3 mechanisms. --> 4) <!-- [rfced] Please review the verbs in the phrase "may be that the cryptographic community may have less confidence". Would updating as shown below be correct? Original: An additional facet of these algorithms may be that the cryptographic community has less confidence in their security due to them being relatively new or less studied. Perhaps: An additional facet of these algorithms is that the cryptographic community may have less confidence in their security due to them being relatively new or less studied. --> 5) <!-- [rfced] Is "for example" needed in these sentences? Original: IND-CCA2 corresponds to security against an active attacker, and the public key / secret key pair can be treated as a long-term key or reused (see for example [KATZ] or [HHK] for definitions of IND-CCA2 and IND-CPA security). ... Diffie-Hellman key exchange, when viewed as a KEM, does not formally satisfy IND-CCA2 security, but is still safe to use for ephemeral key exchange in TLS 1.3, see for example [DOWLING]. ... For additional perspectives on the general transition from traditional to post-quantum cryptography, see for example [ETSI], among others. Perhaps: IND-CCA2 corresponds to security against an active attacker, and the public key and secret key pair can be treated as a long-term key or reused (see [KATZ] or [HHK] for definitions of IND-CCA2 and IND-CPA security). ... Diffie-Hellman key exchange, when viewed as a KEM, does not formally satisfy IND-CCA2 security but is still safe to use for ephemeral key exchange in TLS 1.3, see [DOWLING]. ... For additional perspectives on the general transition from traditional to post-quantum cryptography, see [ETSI]. --> 6) <!-- [rfced] Please review the placement of the parenthetical that starts with "see, for example, [KATZ]" in the second sentence below (the surrounding text is provided for context). Note that IND-CPA is not discussed until the following paragraph. Would it be helpful to make the parenthetical a complete sentence and place it in a new paragraph after the paragraph about IND-CPA? Original: The main security property for KEMs is indistinguishability under adaptive chosen ciphertext attack (IND-CCA2), which means that shared secret values should be indistinguishable from random strings even given the ability to have other arbitrary ciphertexts decapsulated. IND-CCA2 corresponds to security against an active attacker, and the public key and secret key pair can be treated as a long-term key or reused (see, for example, [KATZ] or [HHK] for definitions of IND-CCA2 and IND-CPA security). A common design pattern for obtaining security under key reuse is to apply the Fujisaki-Okamoto (FO) transform [FO] or a variant thereof [HHK]. A weaker security notion is indistinguishability under chosen plaintext attack (IND-CPA), which means that the shared secret values should be indistinguishable from random strings given a copy of the public key. IND-CPA roughly corresponds to security against a passive attacker and sometimes corresponds to one-time key exchange. Perhaps: The main security property for KEMs is indistinguishability under adaptive chosen ciphertext attack (IND-CCA2), which means that shared secret values should be indistinguishable from random strings even given the ability to have other arbitrary ciphertexts decapsulated. IND-CCA2 corresponds to security against an active attacker, and the public key and secret key pair can be treated as a long-term key or reused. A common design pattern for obtaining security under key reuse is to apply the Fujisaki-Okamoto (FO) transform [FO] or a variant thereof [HHK]. A weaker security notion is indistinguishability under chosen plaintext attack (IND-CPA), which means that the shared secret values should be indistinguishable from random strings given a copy of the public key. IND-CPA roughly corresponds to security against a passive attacker and sometimes corresponds to one-time key exchange. See [KATZ] or [HHK] for definitions of IND-CCA2 and IND-CPA security. --> 7) <!-- [rfced] May we add numbers to this long sentence improve readability? Original: DH key exchange can be modeled as a KEM, with KeyGen corresponding to selecting an exponent x as the secret key and computing the public key g^x; encapsulation corresponding to selecting an exponent y, computing the ciphertext g^y and the shared secret g^(xy), and decapsulation as computing the shared secret g^(xy). Perhaps: DH key exchange can be modeled as a KEM, with (1) KeyGen corresponding to selecting an exponent x as the secret key and computing the public key g^x, (2) encapsulation corresponding to selecting an exponent y and computing the ciphertext g^y and the shared secret g^(xy), and (3) decapsulation corresponding to computing the shared secret g^(xy). --> 8) <!-- [rfced] May we update this sentence as follows to clarify "Here"? In the suggested text below, we removed "Here" and added "for the calculation of shared secrets" after "concatenation approach". Original: Here this document also takes a simple "concatenation approach": the two shared secrets are concatenated together and used as the shared secret in the existing TLS 1.3 key schedule. Perhaps: This document also takes a simple "concatenation approach" for the calculation of shared secrets: The two shared secrets are concatenated together and used as the shared secret in the existing TLS 1.3 key schedule. --> 9) <!-- [rfced] The following line exceeds the 72-character line limit for artwork. Please let us know how it can be modified. Original: concatenated_shared_secret = MyECDH.shared_secret || MyPQKEM.shared_secret --> 10) <!--[rfced] May we update "non-approved" to "unapproved" in the sentence below? Original: Some hybrid combinations may combine the shared secret from a NIST-approved algorithm (e.g., ECDH using the nistp256/secp256r1 curve) with a shared secret from a non-approved algorithm (e.g., post-quantum). Perhaps: Some hybrid combinations may combine the shared secret from a NIST-approved algorithm (e.g., ECDH using the nistp256/secp256r1 curve) with a shared secret from an unapproved algorithm (e.g., post-quantum). --> 11) <!-- [rfced] Would adding a reference for "Classic McEliece" be helpful here? If so, please provide the reference entry. Original: Some post-quantum KEMs have larger public keys and/or ciphertexts; for example, Classic McEliece's smallest parameter set has public key size 261,120 bytes. --> 12) <!-- [rfced] IANA Considerations section a) The only mention of this document in the "TLS Supported Groups" registry is the Reference at the top of the registry. We have thus added a sentence to the IANA Considerations section to indicate this (see Current below). The rest of the text in the IANA Considerations section seems to be contain instructions for future registrations in the registry. Link to registry: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml b) How may we clarify "range that is distinct from the Finite Field Groups range"? We see two ranges in the registry that include "Finite Field Diffie-Hellman groups" in the Notes column. We could note that there are two ranges from which assignments should not be made (see Perhaps A), or we could update to specify the ranges from which assignments per this document should be made (see Perhaps B). Note that for Perhaps B, we used ranges 0-255 and 512-65535 because they both indicate that the Recommended column be set to "N". Original: IANA will assign identifiers from the TLS Supported Groups registry [IANATLS] for the hybrid combinations defined following this document. These assignments should be made in a range that is distinct from the Finite Field Groups range. For these entries in the TLS Supported Groups registry, the "Recommended" column SHOULD be "N" and the "DTLS-OK" column SHOULD be "Y". Current: IANA has added this document as a reference for the "TLS Supported Groups" registry" [IANA-TLS]. For hybrid combinations that are defined per this document, IANA will assign identifiers in a range that is distinct from the Finite Field Groups range. In addition, the "Recommended" column SHOULD be "N", and the "DTLS-OK" column SHOULD be "Y". Perhaps A: IANA has added this document as a reference for the "TLS Supported Groups" registry" [IANA-TLS]. For hybrid combinations that are defined per this document, IANA will assign identifiers in a range that is distinct from the ranges for "Finite Field Diffie-Hellman groups". In addition, the "Recommended" column SHOULD be "N", and the "DTLS-OK" column SHOULD be "Y". Perhaps B: IANA has added this document as a reference for the "TLS Supported Groups" registry" [IANA-TLS]. For hybrid combinations that are defined per this document, IANA will assign identifiers in the ranges 0-255 and 512-65535 (not in the ranges 256-511 or 256-511, which are for "Finite Field Diffie Hellman groups"). In addition, the "Recommended" column SHOULD be "N", and the "DTLS-OK" column SHOULD be "Y". --> 13) <!-- [rfced] References a) Note that draft-tjhai-ipsecme-hybrid-qske-ikev2 was replaced by draft-ietf-ipsecme-ikev2-multiple-ke and published as RFC 9370. May we update this reference entry to RFC 9370? Current: [IKE-HYBRID] Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S., Van Geest, D., Garcia-Morchon, O., and V. Smyslov, "Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2)", Work in Progress, Internet-Draft, draft-tjhai-ipsecme-hybrid-qske-ikev2-04, 9 July 2019, <https://datatracker.ietf.org/doc/html/draft- tjhai-ipsecme-hybrid-qske-ikev2-04>. Perhaps: [RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May 2023, <https://www.rfc-editor.org/info/rfc9370>. a.1) Related to the above, if [IKE-HYBRID] is updated to [RFC9370], are any changes needed to the text that includes the citation? Current: Considering other IETF standards, there is work on post-quantum preshared keys in Internet Key Exchange Protocol Version 2 (IKEv2) [IKE-PSK] and a framework for hybrid key exchange in IKEv2 [IKE-HYBRID]. Perhaps: [RFC9370] on the multiple key exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) has been published as a Proposed Standard, and other IETF work includes a framework for hybrid key exchange in IKEv2 [IKE-HYBRID]. b) Note that draft-kwiatkowski-tls-ecdhe-mlkem was replaced by draft-ietf-tls-ecdhe-mlkem. Should this reference be updated to point to the newer document? Current: [ECDHE-MLKEM] Kwiatkowski, K., Kampanakis, P., Westerbaan, B., and D. Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3", Work in Progress, Internet-Draft, draft- kwiatkowski-tls-ecdhe-mlkem-03, 24 December 2024, <https://datatracker.ietf.org/doc/html/draft-kwiatkowski- tls-ecdhe-mlkem-03>. Perhaps: [ECDHE-MLKEM] Kwiatkowski, K., Kampanakis, P., Westerbaan, B., and D. Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3", Work in Progress, Internet-Draft, draft- ietf-tls-ecdhe-mlkem-04, 8 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-tls- ecdhe-mlkem-04>. c) FYI: We updated the following references to match reference style guidance for referencing web-based public code repositories (e.g., GitHub). See <https://www.rfc-editor.org/styleguide/part2/#ref_repo> for more information. Original: [OQS-102] Open Quantum Safe Project, "OQS-OpenSSL-1-0-2_stable", November 2018, <https://github.com/open-quantum- safe/openssl/tree/OQS-OpenSSL_1_0_2-stable>. [OQS-111] Open Quantum Safe Project, "OQS-OpenSSL-1-1-1_stable", January 2022, <https://github.com/open-quantum- safe/openssl/tree/OQS-OpenSSL_1_1_1-stable>. [OQS-PROV] Open Quantum Safe Project, "OQS Provider for OpenSSL 3", July 2023, <https://github.com/open-quantum-safe/oqs-provider/>. Current: [OQS-102] "OQS-OpenSSL-1-0-2_stable", commit 537b2f9, 31 January 2020, <https://github.com/open-quantum-safe/openssl/tree/ OQS-OpenSSL_1_0_2-stable>. [OQS-111] "OQS-OpenSSL-1-1-1_stable", commit 5f49b7a, 8 January 2025, <https://github.com/open-quantum-safe/openssl/tree/ OQS-OpenSSL_1_1_1-stable>. [OQS-PROV] "OQS Provider for OpenSSL 3", commit 573fb25, 8 January 2026, <https://github.com/open-quantum-safe/oqs-provider/>. --> 14) <!--[rfced] Abbreviations a) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Internet Key Exchange Protocol Version 2 (IKEv2) Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) eXtended Merkle Signature Scheme (XMSS) b) Both the expansion and the acronym for the following terms are used throughout the document. Would you like to update to using the expansion upon first usage and the acronym for the rest of the document? Diffie-Hellman (DH) elliptic curve (EC) Fujisaki-Okamoto (FO) key encapsulation mechanism (KEM) --> 15) <!-- [rfced] We updated <artwork> to <sourcecode> in Section 3.2. Please review and let us know how/if the "type" attribute should be set for these. Perhaps as type="tls-presentation" or type="pseudocode"? The current list of preferred values for "type" is available at <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. --> 16) <!--[rfced] The questions below relate to the use of <em> in the document. Note that <em> produces bold in the HTML/PDF outputs and encloses text with asterisks in the TXT output. For more information about <em>, see https://authors.ietf.org/en/rfcxml-vocabulary#em. a) Section 1.4 ("Goals"): Is <em> needed in the unordered list? In particular, please review the appearance in the TXT output (i.e., asterisks are used for bullets and also used around the items enclosed in <em>). b) Section 3.3: The text enclosed in <em> is not a complete sentence. Is the intent to combine with the following sentence (Perhaps A), create a sub-section (Perhaps B), or something else? Original: *FIPS-compliance of shared secret concatenation.* The US National Institute of Standards and Technology (NIST) documents [NIST-SP-800-56C] and [NIST-SP-800-135] give recommendations for key derivation methods in key exchange protocols. ... Perhaps A: In regard to FIPS compliance, the US National Institute of Standards and Technology (NIST) documents [NIST-SP-800-56C] and [NIST-SP-800-135] give recommendations for key derivation methods in key exchange protocols. ... Perhaps B: 3.3.1. FIPS Compliance The US National Institute of Standards and Technology (NIST) documents [NIST-SP-800-56C] and [NIST-SP-800-135] give recommendations for key derivation methods in key exchange protocols. ... c) Section 4: May we remove the <em> and update to use either <dl> (Perhaps A) or separate subsections (Perhaps B)? Original *Larger public keys and/or ciphertexts.* The key_exchange field in the KeyShareEntry struct in Section 3.2 limits public keys and ciphertexts to 2^16-1 bytes. ... *Duplication of key shares.* Concatenation of public keys in the key_exchange field in the KeyShareEntry struct as described in Section 3.2 can result in sending duplicate key shares. Perhaps A: Larger public keys and/or ciphertexts: The key_exchange field in the KeyShareEntry struct in Section 3.2 limits public keys and ciphertexts to 2^16-1 bytes. ... ... Duplication of key shares: Concatenation of public keys in the key_exchange field in the KeyShareEntry struct as described in Section 3.2 can result in sending duplicate key shares. ... Perhaps B: 4.1. Larger Public Keys and/or Ciphertexts The key_exchange field in the KeyShareEntry struct in Section 3.2 limits public keys and ciphertexts to 2^16-1 bytes. ... ... 4.2. Duplication of Key Shares Concatenation of public keys in the key_exchange field in the KeyShareEntry struct as described in Section 3.2 can result in sending duplicate key shares. d) Section 6: Please confirm that <em> is intended for the entire sentence here. Original: *Public keys, ciphertexts, and secrets should be constant length.* This document assumes that the length of each public key, ciphertext, and shared secret is fixed once the algorithm is fixed. This is the case for ML-KEM. --> 17) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether "master" should be updated. In addition, please consider whether "traditional" should be updated for clarity. While the NIST website indicates that this term is potentially biased, it is also ambiguous. "Traditional" is a subjective term, as it is not the same for everyone. Link to NIST website: https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1 --> Thank you. Alanna Paloma and Rebecca VanRheenen RFC Production Center On Apr 3, 2026, at 9:41 AM, [email protected] wrote: *****IMPORTANT***** Updated 2026/04/03 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * [email protected] (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * [email protected], which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, [email protected] will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9954.xml https://www.rfc-editor.org/authors/rfc9954.html https://www.rfc-editor.org/authors/rfc9954.pdf https://www.rfc-editor.org/authors/rfc9954.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9954-diff.html https://www.rfc-editor.org/authors/rfc9954-rfcdiff.html (side by side) For your convenience, we have also created an alt-diff file that will allow you to more easily view changes where text has been deleted or moved: https://www.rfc-editor.org/authors/rfc9954-alt-diff.html Diff of the XML: https://www.rfc-editor.org/authors/rfc9954-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9954 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9954 (draft-ietf-tls-hybrid-design-16) Title : Hybrid key exchange in TLS 1.3 Author(s) : D. Stebila, S. Fluhrer, S. Gueron WG Chair(s) : Joseph A. Salowey, Sean Turner, Deirdre Connolly Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
