Larger Data in TLS 1.3 Handshake

Possible Solutions to the Problem

New Key Share Extension Based on the key share extension from is introduced a new key share extension in this document, "key_share_pqc". This is reflected in this document and is represented as KeyShareEntryPQC below, based on the existing KeyShareEntry from . However, this is modified along with the existing KeyShareEntry structure to test if the key exchange algorithm chosen in a TLS 1.3 connection belongs from the Classic McEliece family, and if it is, then KeyShareEntryPQC is constructed. If the opposite is true, where the key exchange algorithm is not from the Classic McEliece family, then KeyShareEntry is constructed. Note that the "key_exchange" fields are expanded in KeyShareEntryPQC to accommodate a large public key that is greater than 65,535 Bytes: ; } } KeyShareEntry; struct { NamedGroup group; select (KeyShareEntryPQC.group) { case classicmceliece348864: opaque key_exchange<1..2^24-1>; case classicmceliece460896: opaque key_exchange<1..2^24-1>; case classicmceliece6688128: opaque key_exchange<1..2^24-1>; case classicmceliece6960119: opaque key_exchange<1..2^24-1>; case classicmceliece8192128: opaque key_exchange<1..2^24-1>; case x25519classicmceliece348864: opaque key_exchange<1..2^24-1>; case rlcel5: opaque key_exchange<1..2^24-1>; case other large PQ algorithm1: opaque key_exchange<1..2^24-1>; case other large PQ algorithm2: opaque key_exchange<1..2^24-1>; case etc.: opaque key_exchange<1..2^24-1>; default: Empty; } } KeyShareEntryPQC; ]]> Note: PQ (Post-Quantum) where "other large PQ algorithm1" and "other large PQ algorithm2" and "etc." above indicates that one or more future post-quantum algorithms with large public key sizes can be added by just defining a constant for each of these post-quantum algorithms. Another Note: An additional algorithm is included in the above, "rlcel5", since it also has a large public key beyond the 65,535 Byte limit. See Section 7 for more information discussing this RLCE algorithm. This is then applied to the existing KeyShareClientHello structure, which originates from , that now contains an additional field for KeyShareEntryPQC: ; KeyShareEntryPQC client_shares<0..2^24-1>; } KeyShareClientHello; ]]> Since the KeyShareClientHello needs to be expanded to accommodate for the KeyShareEntryPQC struct, the same applies to the existing Extension struct, originated as well from but "extension_data" is now expanded: ; } Extension; ]]> Since there is a new key share extension to accommodate keys larger than the 65,535 Byte limit (KeyShareEntryPQC), this is reflected in the existing ExtensionType structure from where this is the new type that holds a value of TBD, "key_share_pqc": Since the "extension_data" field will be much larger for a KeyShareClientHello that contains a large public key that is greater than the previously defined 65,535 Byte limit, an example being a Classic McEliece public key, the server must be able to handle this circumstance when receiving the ClientHello message. One way is to compare the value for a packet that contains extensions including a large public key from the ClientHello message to a macro constant (for example, "CLIENT_HELLO_MIN_EXT_LENGTH" as defined in this introduced TLS implementation in this paper, see and ) and if this packet value is longer than this constant, the server will change the way it normally handles all of the extensions. This constant could be easily modified in the aforementioned TLS Open Secure Socket Layer (OpenSSL) implementation. The process of how the server collects the extensions from a ClientHello message must also be modified, as the server must be able to process the new key share extension differently than the other extensions, should the server see this inside a ClientHello message. For example, see . The ServerHello message is modified as well where the KeyShareServerHello structure originates from : This new "key_share_pqc" extension is therefore can be implemented in the full TLS handshake, where Figure 1 from is modified to be the following:

Full TLS Handshake with "key_share_pqc" extension ServerHello ^ Key + key_share* | Exch + key_share_pqc* | + pre_shared_key* v {EncryptedExtensions} ^ Server {CertificateRequest*} v Params {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data] + Indicates noteworthy extensions sent in the previously noted message. * Indicates optional or situation-dependent messages/extensions that are not always sent. {} Indicates messages protected using keys derived from a [sender]_handshake_traffic_secret. [] Indicates messages protected using keys derived from [sender]_application_traffic_secret_N. ]]>

Modification to PskKeyExchangeMode structure There are two key establishments that are considered when examining the structure of PskKeyExchangeMode from . Since there is no Diffie Hellman algorithm in use with a pre-shared key (PSK) when considering the use of a Classic McEliece algorithm for key exchange, then there must be another key exchange mode to utilize in this case. Therefore, this is reflected in the existing PskKeyExchangeMode structure below where "psk_pqc_ke(2)" is added: When selecting a Classic McEliece algorithm and using an external PSK or a resumption PSK, "02" will then be listed for the "psk_key_exchange_modes" extension along with the new "key_share_pqc" extension in the ClientHello message. At the end of this ClientHello message is printed the "00 29" extension (pre-shared key extension), where the PSK identity should be printed and is mapped to the binder that should proceed it in this pre-shared key extension. The ServerHello message will also contain the new "key_share_pqc" extension, and will as well contain the pre-shared key extension, where it should contain "00 00" at the end which represents the server selecting the PSK identity of 0 (for example: the Selected Identity of 0 shown in the pre-shared key extension in a ServerHello message in this Wireshark example: ). Overall, this is a new key exchange selecting a Classic McEliece algorithm using a PSK, whether its external or resumption, and this can be demonstrated in the TLS Implementation below. As stated above, resumption PSK with a Classic McEliece algorithm chosen as a key exchange algorithm involves the use of the new "key_share_pqc" extension for both the ClientHello and ServerHello messages. Thus, the Resumption and PSK Message Flow diagram (which originates from Figure 3 of ) is derived for this situation and has been tested with the TLS Implementation mentioned in this document:

Resumption with "key_share_pqc" extension ServerHello key_share_pqc EncryptedExtensions Certificate CertificateVerify <--------- Finished Finished ----------> <--------- NewSessionTicket <--------- NewSessionTicket Subsequent Handshake ClientHello key_share_pqc pre_shared_key ---------> ServerHello key_share_pqc pre_shared_key EncryptedExtensions <--------- Finished Finished ----------> <--------- NewSessionTicket ]]>

Hello Retry Request using New Key Share Extension In a Hello Retry Request scenario, the first ClientHello message will have two algorithms listed in its "supported_groups" extension, where the numerical identifier (NID) for the algorithm that is no longer recognized by the server as an acceptable algorithm will first be listed in this extension, followed by the NID for a Classic McEliece algorithm. In this same ClientHello message is where "02" will be listed in the "psk_key_exchange_modes" extension, and the original "key_share" extension (value 51) is also shown with its public key for the unacceptable algorithm. When the server responds with the HelloRetryRequest message, the random is the same special value for SHA-256 as indicated in Section 4.1.3 of , and has the same exact fields ("legacy_version", "random", "legacy_session_id_echo", "cipher_suite", "legacy_compression_method", and "extensions") as in the ServerHello structure indicated in (see section 4.1.3). The extensions field not only consists of the "supported_versions" extension, but also the new "key_share_pqc" extension where the server offers the client the Classic McEliece algorithm NID it shares with the client. When the client sends a second ClientHello in response to the HelloRetryRequest, this will be the same message as the first ClientHello with one exception: the original "key_share" extension is replaced with the new "key_share_pqc" extension which contains the large public key of a Classic McEliece algorithm. Then the ServerHello message will then respond containing the new "key_share_pqc" extension. Therefore, this Hello Retry Request scenario is reflected in Figure 3 below, which is a modification of Figure 2 in , and this can be demonstrated in the TLS Implementation mentioned in this documentation:

Handshake with HelloRetryRequest with "key_share_pqc" extension HelloRetryRequest <-------- key_share_pqc ClientHello key_share_pqc --------> ServerHello key_share_pqc EncryptedExtensions Certificate CertificateVerify <-------- Finished Finished --------> <-------- NewSessionTicket <-------- NewSessionTicket ]]> Note: When the client processes the HelloRetryRequest message, it must mark the new "key_share_pqc" extension as an unsolicited extension, which would be an additional exception to the rule noted in regarding extension responses MUST NOT be sent if the corresponding extension requests were not sent by a remote endpoint (see section 4.2 in ). The following structure would remain intact from , since support would already be provided for a Classic McEliece algorithm being in NamedGroup (see Section 4): When a Hello Retry Request involves a PSK in use with a Classic McEliece algorithm, both the first and second ClientHello messages (the second one being sent after a HelloRetryRequest message) will contain the exact same content except the first ClientHello will have the original "key_share" extension and the second ClientHello will have the new "key_share_pqc" extension. Another exception includes different binders in both ClientHello messages' pre-shared key extensions. This pre-shared key extension appears as the last extension in both ClientHello messages as well in the ServerHello message.

Other Use Case (RLCE Algorithm) The Random Linear Code-based Encryption (RLCE) algorithm group (see ) is another code-based cryptographic scheme (NIST Round 1 ). "rlcel5" is a RLCE algorithm from this group (where the public key size is 1,232,001 Bytes) that can be used in the new key share extension, and can be demonstrated for use for TLS key exchange in the TLS Implementation mentioned in this document.

Hybrid Combination "x25519classicmceliece348864" "x25519classicmceliece348864" is a hybrid mechanism introduced in this document that combines both classicmceliece348864 and x25519 in TLS key exchanges. The experiment TLS implementation presented in this document, which uses the fork of the oqs-provider , is one example of using x25519classicmceliece348864 in a hybrid key exchange; when x25519classicmceliece348864 is chosen in this circumstance, it uses the "concatenating" method mentioned in in the new key_share_pqc extension. In the ClientHello message, this new key share extension contains both the Classic McEliece public key and X25519 key concatenated together. In the ServerHello message, this new key share extension then contains the classicmceliece348864 ciphertext and X25519 key concatenated together.

TLS Implementation A TLS implementation exists that tests the use of a new key share extension for both the ClientHello and ServerHello messages that is implemented for OpenSSL, and also where the mentioned Classic McEliece algorithms can be chosen for key exchange when initiating TLS connections. It can be accessed here: .

Summary of Changes from RFC 8446 A new structure is introduced of KeyShareEntryPQC along with modifications of existing structures including KeyShareEntry, NamedGroup, Extension, ExtensionType, KeyShareClientHello, and KeyShareServerHello. Adding a new ExtensionType of "key_share_pqc" allows for the addition of this new structure of KeyShareEntryPQC, which is based on the existing KeyShareEntry, but "key_exchange" has been expanded and select statements are added to both structures which depend on the KeyShareEntry.group or KeyShareEntryPQC.group being called in a TLS connection for key exchange. This new KeyShareEntryPQC will now also appear in existing structures of KeyShareClientHello and KeyShareServerHello. Thus, the "extension_data" is expanded in the existing Extension structure.

Post-handshake Key Exchange with Extended Key Update 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 ).

Additional Key Exchange with Extended Key Update 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] ]]>

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

Using the AuxHandshakeData Message in TLS Handshake 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] ]]>

Definition of AuxHandshakeData

Format of AuxHandshakeData ; } 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; ]]>