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

[Douglas Stebila <[e-mail]>]

I approve, thank you for the updates.

Douglas


> On May 5, 2026, at 11:34 AM, Alanna Paloma <[e-mail]> wrote:
> 
> Hi Authors,
> 
> We have noted Scott’s and Shay’s approvals on the AUTH48 status page:
> https://www.rfc-editor.org/auth48/rfc9954
> 
> Per discussion in the email thread regarding inclusive language, we have updated “Master” to “Main” in Figure 1.
> 
> The files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9954.xml
> https://www.rfc-editor.org/authors/rfc9954.txt
> https://www.rfc-editor.org/authors/rfc9954.html
> https://www.rfc-editor.org/authors/rfc9954.pdf
> 
> The relevant diff files have been posted here:
> https://www.rfc-editor.org/authors/rfc9954-diff.html(comprehensive diff)
> https://www.rfc-editor.org/authors/rfc9954-auth48diff.html(AUTH48 changes)
> https://www.rfc-editor.org/authors/rfc9954-auth48rfcdiff.html(AUTH48 changes side by side)
> https://www.rfc-editor.org/authors/rfc9954-lastdiff.html (last version to this one)
> https://www.rfc-editor.org/authors/rfc9954-lastrfcdiff.html (rfcdiff between last version and this)
> 
> Once we receive approvals from Paul (regarding the update to “Main”) and Douglas, we will move this document forward in the publication process. 
> 
> Thank you,
> Alanna Paloma
> RFC Production Center
> 
>> On May 4, 2026, at 8:53 PM, Shay Gueron <[e-mail]> wrote:
>> 
>> Looks good to me too. 
>> Thanks, Shay Gueron
>> 
>> 
>> On Tue, May 5, 2026 at 12:33 AM Scott Fluhrer (sfluhrer) <[e-mail]> wrote:
>> Looks good to me
>> 
>> From: Alanna Paloma <[e-mail]>
>> Sent: Monday, May 4, 2026 11:40 AM
>> To: Douglas Stebila <[e-mail]>; Scott Fluhrer (sfluhrer) <[e-mail]>; [e-mail] <[e-mail]>
>> Cc: Sean Turner <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
>> Subject: Re: AUTH48: RFC-to-be 9954 <draft-ietf-tls-hybrid-design-16> for your review 
>> 
>> Hi Authors,
>> 
>> This is a friendly reminder that we await your reviews and approvals of the updated files. We will await approvals from each party listed on the AUTH48 status
>> page below prior to moving this document forward in the publication process.
>> 
>> The files have been posted here (please refresh):
>> https://www.rfc-editor.org/authors/rfc9954.xml
>> https://www.rfc-editor.org/authors/rfc9954.txt
>> https://www.rfc-editor.org/authors/rfc9954.html
>> https://www.rfc-editor.org/authors/rfc9954.pdf
>> 
>> The relevant diff files have been posted here:
>> https://www.rfc-editor.org/authors/rfc9954-diff.html(comprehensive diff)
>> https://www.rfc-editor.org/authors/rfc9954-auth48diff.html(AUTH48 changes)
>> https://www.rfc-editor.org/authors/rfc9954-auth48rfcdiff.html(AUTH48 changes side by side)
>> https://www.rfc-editor.org/authors/rfc9954-lastdiff.html (last version to this one)
>> https://www.rfc-editor.org/authors/rfc9954-lastrfcdiff.html (rfcdiff between last version and this)
>> 
>> For the AUTH48 status of this document, please see:
>> https://www.rfc-editor.org/auth48/rfc9954
>> 
>> Thank you,
>> Alanna Paloma
>> RFC Production Center
>> 
>>> On Apr 27, 2026, at 2:06 PM, Alanna Paloma <[e-mail]> wrote:
>>> 
>>> Hi Douglas,
>>> 
>>> We’ve fixed the typos and updated the reference to TLS 1.3 to point to RFC-to-be 9846.
>>> 
>>> FYI - RFC-to-be 9846 has been in AUTH48 state since December because an issue was being discussed. While we believe the issue may be resolved, we have not yet received further instruction for that document.
>>> 
>>> The files have been posted here (please refresh):
>>> https://www.rfc-editor.org/authors/rfc9954.xml
>>> https://www.rfc-editor.org/authors/rfc9954.txt
>>> https://www.rfc-editor.org/authors/rfc9954.html
>>> https://www.rfc-editor.org/authors/rfc9954.pdf
>>> 
>>> The relevant diff files have been posted here:
>>> https://www.rfc-editor.org/authors/rfc9954-diff.html(comprehensive diff)
>>> https://www.rfc-editor.org/authors/rfc9954-auth48diff.html(AUTH48 changes)
>>> https://www.rfc-editor.org/authors/rfc9954-auth48rfcdiff.html(AUTH48 changes side by side)
>>> https://www.rfc-editor.org/authors/rfc9954-lastdiff.html (last version to this one)
>>> https://www.rfc-editor.org/authors/rfc9954-lastrfcdiff.html (rfcdiff between last version and this)
>>> 
>>> For the AUTH48 status of this document, please see:
>>> https://www.rfc-editor.org/auth48/rfc9954
>>> 
>>> Thank you,
>>> Alanna Paloma
>>> RFC Production Center
>>> 
>>>> On Apr 24, 2026, at 11:47 AM, Douglas Stebila <[e-mail]> wrote:
>>>> 
>>>> Fine with me.
>>>> 
>>>> Douglas
>>>> 
>>>> 
>>>>> On Apr 24, 2026, at 1:50 PM, Sean Turner <[e-mail]> wrote:
>>>>> 
>>>>> The RFC editor could swap out the RFC8446 and the links to it with the RFC # - like so:
>>>>> 
>>>>> e.g.,
>>>>> 
>>>>> [TLS13]    Rescorla, E., "The Transport Layer Security (TLS) Protocol
>>>>>           Version 1.3", RFC XXXX, DOI 10.17487/RFCXXXX, Month 2026,
>>>>>           <https://www.rfc-editor.org/info/rfcXXXX>.
>>>>> 
>>>>> spt
>>>>> 
>>>>>> On Apr 24, 2026, at 11:24, Douglas Stebila <[e-mail]> wrote:
>>>>>> 
>>>>>> Hi Sean,
>>>>>> 
>>>>>> Would it switch RFC8446 to refer to it as draft-ietf-tls-rfc8446bis, or to refer to it under its RFC number?  I don’t have my own opinion as to whether it’s preferable to refer to 8446 or the newer version, and defer to the IETF process experts on that.
>>>>>> 
>>>>>> Douglas
>>>>>> 
>>>>>> 
>>>>>>> On Apr 24, 2026, at 10:52 AM, Sean Turner <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Authors,
>>>>>>> 
>>>>>>> You might not be aware that -rfc8446bis is also in the RFC editor’s queue; crossing fingers it will be also be published in the coming weeks. If you want (and I want to make it clear you DO NOT need to agree to this), you could swap out the [RFC8446] reference to refer to draft-ietf-tls-rfc8446bis. This would set up a dependency, but it might be worth it to avoid a soon to be outdated reference.
>>>>>>> 
>>>>>>> spt
>>>>>>> 
>>>>>>>> On Apr 24, 2026, at 10:25, Alanna Paloma <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Hi Douglas,
>>>>>>>> 
>>>>>>>> Thank you for your reply.  We have updated as requested.
>>>>>>>> 
>>>>>>>> The files have been posted here (please refresh):
>>>>>>>> https://www.rfc-editor.org/authors/rfc9954.xml
>>>>>>>> https://www.rfc-editor.org/authors/rfc9954.txt
>>>>>>>> https://www.rfc-editor.org/authors/rfc9954.html
>>>>>>>> https://www.rfc-editor.org/authors/rfc9954.pdf
>>>>>>>> 
>>>>>>>> The relevant diff files have been posted here:
>>>>>>>> https://www.rfc-editor.org/authors/rfc9954-diff.html (comprehensive diff)
>>>>>>>> https://www.rfc-editor.org/authors/rfc9954-auth48diff.html (AUTH48 changes)
>>>>>>>> https://www.rfc-editor.org/authors/rfc9954-auth48rfcdiff.html (AUTH48 changes side by side)
>>>>>>>> 
>>>>>>>> Please review the document carefully and contact us with any further updates you may have.  Note that we do not make changes once a document is published as an RFC.
>>>>>>>> 
>>>>>>>> We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process.
>>>>>>>> 
>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>> https://www.rfc-editor.org/auth48/rfc9954
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> Alanna Paloma
>>>>>>>> RFC Production Center
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Apr 20, 2026, at 2:58 PM, Douglas Stebila <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>