[TLS] [Errata Verified] RFC9954 (9136)

The following errata report has been verified for RFC9954,
"Hybrid Key Exchange in TLS 1.3"

--------------------------------------
You may review the report below and at:
https://errata.rfc-editor.org/eid9136/

--------------------------------------

Status: Verified
Type: Editorial
Reported by: Nikolai Malykh <[email protected]>
Date Reported: Aug. 17, 2026, 8:57 a.m.
Verified by: Madison Church (RFC Production Center)

Section 3.2 says:

Original Text
-------------
Recall that, in TLS 1.3 ([TLS13], Section 4.2.8), a KEM public key or
KEM ciphertext is represented as a KeyShareEntry:

       struct {
           NamedGroup group;
           opaque key_exchange<1..2^16-1>;
       } KeyShareEntry;

   These are transmitted in the extension_data fields of
   KeyShareClientHello and KeyShareServerHello extensions:

       struct {
           KeyShareEntry client_shares<0..2^16-1>;
       } KeyShareClientHello;

       struct {
           KeyShareEntry server_share;
       } KeyShareServerHello;

   The client's shares are listed in descending order of client
   preference; the server selects one algorithm and sends its
   corresponding share.

   For a hybrid key exchange, the key_exchange field of a KeyShareEntry
   is the concatenation of the key_exchange field for each of the
   constituent algorithms.  The order of shares in the concatenation
   MUST be the same as the order of algorithms indicated in the
   definition of the NamedGroup.

   For the client's share, the key_exchange value contains the
   concatenation of the pk outputs of the corresponding KEMs' KeyGen
   algorithms if that algorithm corresponds to a KEM or the (EC)DH
   ephemeral key share if that algorithm corresponds to an (EC)DH group.
   For the server's share, the key_exchange value contains the
   concatenation of the ct outputs of the corresponding KEMs' Encaps
   algorithms if that algorithm corresponds to a KEM or the (EC)DH
   ephemeral key share if that algorithm corresponds to an (EC)DH group.

   Section 4.2.8 of [TLS13] requires that "The key_exchange values for
   each KeyShareEntry MUST be generated independently."  In the context
   of this document, the same algorithm may appear in multiple named
   groups; thus, this document relaxes the above requirement to allow
   the same key_exchange value for the same algorithm to be reused in
   multiple KeyShareEntry records sent within the same ClientHello.
   However, key_exchange values for different algorithms MUST be
   generated independently.  Explicitly, if the NamedGroup is the hybrid
   key exchange MyECDHMyPQKEM, the KeyShareEntry.key_exchange values
   MUST be generated in one of the following two ways:

Corrected Text
--------------
Recall that, in TLS 1.3 ([TLS13], Section 4.3.8), a KEM public key or
KEM ciphertext is represented as a KeyShareEntry:

       struct {
           NamedGroup group;
           opaque key_exchange<1..2^16-1>;
       } KeyShareEntry;

   These are transmitted in the extension_data fields of
   KeyShareClientHello and KeyShareServerHello extensions:

       struct {
           KeyShareEntry client_shares<0..2^16-1>;
       } KeyShareClientHello;

       struct {
           KeyShareEntry server_share;
       } KeyShareServerHello;

   The client's shares are listed in descending order of client
   preference; the server selects one algorithm and sends its
   corresponding share.

   For a hybrid key exchange, the key_exchange field of a KeyShareEntry
   is the concatenation of the key_exchange field for each of the
   constituent algorithms.  The order of shares in the concatenation
   MUST be the same as the order of algorithms indicated in the
   definition of the NamedGroup.

   For the client's share, the key_exchange value contains the
   concatenation of the pk outputs of the corresponding KEMs' KeyGen
   algorithms if that algorithm corresponds to a KEM or the (EC)DH
   ephemeral key share if that algorithm corresponds to an (EC)DH group.
   For the server's share, the key_exchange value contains the
   concatenation of the ct outputs of the corresponding KEMs' Encaps
   algorithms if that algorithm corresponds to a KEM or the (EC)DH
   ephemeral key share if that algorithm corresponds to an (EC)DH group.

   Section 4.3.8 of [TLS13] requires that "The key_exchange values for
   each KeyShareEntry MUST be generated independently."  In the context
   of this document, the same algorithm may appear in multiple named
   groups; thus, this document relaxes the above requirement to allow
   the same key_exchange value for the same algorithm to be reused in
   multiple KeyShareEntry records sent within the same ClientHello.
   However, key_exchange values for different algorithms MUST be
   generated independently.  Explicitly, if the NamedGroup is the hybrid
   key exchange MyECDHMyPQKEM, the KeyShareEntry.key_exchange values
   MUST be generated in one of the following two ways:

Notes
-----
There is a typo in the section number - 4.2.8 instead of 4.3.8

--------------------------------------
RFC9954 (draft-ietf-tls-hybrid-design)
--------------------------------------
Title               : Hybrid Key Exchange in TLS 1.3
Publication Date    : July 2026
Author(s)           : D. Stebila, S. Fluhrer, S. Gueron
Category            : Informational
Source              : tls (sec)
Stream              : IETF

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]