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

[Alanna Paloma <[e-mail]>]

Greetings,

We do not believe we have heard from you regarding this document's readiness for publication.  Please review our previous messages describing the AUTH48 process and containing any document-specific questions we may have had.

We will wait to hear from you before continuing with the publication process.

The AUTH48 status page for this document is located here:
https://www.rfc-editor.org/auth48/rfc9954

Thank you,
Alanna Paloma
RFC Production Center

> On Apr 3, 2026, at 9:44 AM, [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
> -->
> 
> 
> 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, [e-mail] 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
> 
>  *  [e-mail] (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).
> 
>  *  [e-mail], 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, 
>       [e-mail] 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
>