[auth48] Re: AUTH48: RFC-to-be 9954 <draft-ietf-tls-hybrid-design-16> for your review

[Douglas Stebila <[e-mail]>]

Please find responses inline below.



> On Apr 3, 2026, at 12:44 PM, [e-mail] wrote:
> 
> 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
> -->

Okay
> 
> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the title) for use on https://www.rfc-editor.org/search. -->

Post-Quantum

> 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.
> -->

Option B

> 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.
> -->

Okay

> 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].
> -->

Please keep “for example”, as the cited references are indeed meant to be examples, not considered definitive.

> 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.
> -->

Okay

> 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).
> -->

Okay

> 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.
> -->

Okay

> 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
> —>

It can be split into two lines with the first character of || lined up with the first character of MyECDH.


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).
> -->   

Okay

> 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.
> -->

Okay, you can use this as an informative reference: https://www.ietf.org/archive/id/draft-josefsson-mceliece-00.html

> 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".
> -->

There is only a single range for Finite Field Diffie-Hellman groups: 256-511.  There happen to be two lines in a table about that range, specifying different instructions depending on the “Recommended” field, but there is only one range.

> 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/>.
> -->

Okay

> 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)
> -->

I would prefer to leave as is and use a mix of expansion and acronym through the rest of the document for readability.

> 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.
> -->

The first two in Section 3.2 (struct… KeyShareEntry and struct … KeyShareServerHello) can be tis-presentation. I think the rest can be pseudocode.

> 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.
> -->   

For (a), (b), (c), these are a stylistically choice to clarify logical organization of the text, and are at your discretion.  For (d), please keep this.

> 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
> -->

“Master Secret” is the term used in RFC 8446.  “Traditional” is the term used in RFC 9794.  Unless those documents are changed, I don’t think the text should be changed here.