Larger Data in TLS 1.3 Handshake

Internet-Draft	Larger Data in TLS 1.3 Handshake	February 2026
Wagner, et al.	Expires 24 August 2026	[Page]

Abstract

This memo discusses possible modifications of TLS 1.3, aimed to allow trasferring data larger than 64 Kbytes in handshake messages. One possible application for this feature is to allow using post-quantum Key Encapsulation Method that have large public key or ciphertext size (like Classic McEliece).¶

3. Possible Solutions to the Problem

3.2. Post-handshake Key Exchange with Extended Key Update

Extended Key Update [I-D.ietf-tls-extended-key-update] is a TLS 1.3 extension that allows to perform post-handshake key exchange in order to update session keys. This mechanism defines new TLS 1.3 handshake message type - ExtendedKeyUpdate. Since TLS 1.3 handshake messages can be up to 2^24 bytes long, this allows to transfer large key shares using this message.¶

Currently, the functionality of Extended Key Update is limited to only allow using exactly the same key exchange mechanism as was negotiated and used during the handshake. However, the mechanism can be extended to also allow performing a different key exchange mechanism, that could be additionally negotiated during the handshake. In this case a modified Extended Key Update must be run immediately after the initial handshake and before any application data sent over the connection. Thus, the resulting key exchange will always be non-composite hybrid key exchange, similar to what IKEv2 does (see [RFC9370]).¶


        Client                                           Server

 Key  ^ ClientHello
 Exch | + key_share
      | + signature_algorithms
      v + additional_key_exchange
                              -------->
                                                   ServerHello  ^ Key
                                                   + key_share  | Exch
                                                                v
                                         {EncryptedExtensions   ^ Server
                                    + additional_key_exchange}  | Params
                                          {CertificateRequest}  v
                                                 {Certificate}  ^
                                           {CertificateVerify}  | Auth
                                                    {Finished}  v
                                <--------
      ^ {Certificate}
 Auth | {CertificateVerify}
      v {Finished}              -------->
  [EKU(key_update_request       -------->
        (with key_share))]
                                <-------- [EKU(key_update_response
                                            (with key_share))]
                                         # Server derives new secrets
                                         # and updates SEND keys here
 # Client derives new secrets
 # and updates RECEIVE keys here
         [EKU(new_key_update)]  -------->
 # Client updates SEND keys here
                                     # Server updates RECEIVE keys here

        [Application Data]      <------->        [Application Data]

Figure 4: Additional Key Exchange with Extended Key Update

3.3. New AuxHandshakeData Handshake Message

If there is a need to send large pieces of data that do not fit into the existing TLS 1.3 handshake messages during the handshake (e.g. in the case of PQ KEM with large public keys, like Classic McEliece) then the client indicates this with new extension of type aux_data (Figure 7) in the ClientHello message. This extension contains no data.¶

If the server supports this extension, it replies with the HelloRetryRequest that also includes the aux_data extension.¶

Once HelloRetryRequest has been received, the client repeats ClientHello and immediately after that sends a new message AuxHandshakeData (Figure 5) which actually contains large data. The server then responds with ServerHello that also is immediately followed by AuxHandshakeData message, preceding all other other handshake messages (e.g. EncryptedExtensions, etc.).¶

The data in the AuxHandshakeData message is organized as an array of AuxHandshakeDataEntry (Figure 4) structures. When a large piece of data should be used in the protocol, it is referenced from the corresponding item in the ClientHello or ServerHello by its index in the AuxHandshakeData message.¶

For example, with large public keys for some PQ KEMs (like Classic McEliece) the key_share representation would be LargeKeyShareRepresentation (Figure 6), which contains the type of representation and, depending on that type, either the key share itself (e.g. for Classic McEliece ciphertext, which is small) or the index of AuxHandshakeDataEntry data elements in the AuxHandshakeData message, which will contain the large key share (e.g. a Classic McEliece public key).¶


           Client                                               Server

           ClientHello
           + key_share
           + aux_data             -------->
                                                     HelloRetryRequest
                                                           + key_share
                                  <--------                 + aux_data
           ClientHello
           + key_share
           + aux_data
           AuxHandshakeData*      -------->
                                                           ServerHello
                                                           + key_share
                                                            + aux_data
                                                     AuxHandshakeData*
                                                 {EncryptedExtensions}
                                                 {CertificateRequest*}
                                                        {Certificate*}
                                                  {CertificateVerify*}
                                                            {Finished}
                                   <--------       [Application Data*]
           {Certificate*}
           {CertificateVerify*}
           {Finished}              -------->
           [Application Data]      <------->        [Application Data]

Figure 5: Using the AuxHandshakeData Message in TLS Handshake


         enum {
             ...
             aux_handshake_data(TBA),
             (65535)
         } HandshakeType;

         struct {
             HandshakeType msg_type;    /* handshake type */
             uint24 length;             /* bytes in message */
             select (Handshake.msg_type) {
                 ...
                 case aux_handshake_data:    AuxHandshakeData;
             };
         } Handshake;

Figure 6: Definition of AuxHandshakeData


           struct {
               opaque  data<0..2^24-1>;
           } AuxHandshakeDataEntry;

           struct {
               AuxHandshakeDataEntry   aux_data<0..2^24-1>;
           } AuxHandshakeData;

       struct {
           uint8 form;
           select (LargeKeyShareRepresentation.type) {
               case 0:     uint16      aux_data_entry_index;
               default:    opaque      key_exchange<0..2^16-1>;
           };
       } LargeKeyShareRepresentation;

       enum {
               ...
               aux_data(TBD),
               (65535)
           } ExtensionType;

       struct {
       } AuxData;

Figure 7: Format of AuxHandshakeData

Larger Data in TLS 1.3 Handshake

Abstract

About This Document

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction

2. Conventions and Definitions

3. Possible Solutions to the Problem

3.2. Post-handshake Key Exchange with Extended Key Update

3.3. New AuxHandshakeData Handshake Message

4. Analyzing of the Proposed Solutions

Acknowledgements

References

Normative References

Informative References

Authors' Addresses