Compact TLS 1.3

2.1. Template-based Specialization

A significant transmission overhead in TLS 1.3 is contributed to by two factors, : - the negotiation of algorithm parameters, and extensions, as well as - the exchange of certificates.¶

TLS 1.3 supports different credential types and modes that are impacted differently by a compression scheme. For example, TLS supports certificate-based authentication, raw public key-based authentication as well as pre-shared key (PSK)-based authentication. PSK-based authentication can be used with externally configured PSKs or with PSKs established through tickets.¶

The basic idea of template-based specialization is that we start with the basic TLS 1.3 handshake, which is fully general and then remove degrees of freedom, eliding parts of the handshake which are used to express those degrees of freedom. For example, if we only support one version of TLS, then it is not necessary to have version negotiation and the supported_versions extension can be omitted.¶

Importantly, this process is performed only for the wire encoding but not for the handshake transcript. The result is that the transcript for a specialized cTLS handshake is the same as the transcript for a TLS 1.3 handshake with the same features used.¶

One way of thinking of this is as if specialization is a stateful compression layer between the handshake and the record layer:¶

+---------------+---------------+---------------+
|   Handshake   |  Application  |     Alert     |
+---------------+---------------+---------------+    +---------+
|               cTLS Compression Layer          |<---| Profile |
+---------------+---------------+---------------+    +---------+
|          cTLS Record Layer / Application      |
+---------------+---------------+---------------+

By assuming that out-of-band agreements took place already prior to the start of the cTLS protocol exchange, the amount of data exchanged can be radically reduced. Because different clients may use different compression templates and because multiple compression templates may be available for use in different deployment environments, a client needs to inform the server about the profile it is planning to use. The profile field in the ClientHello serves this purpose.¶

Although the template-based specialization mechanisms described here are general, we also include specific mechanism for certificate-based exchanges because those are where the most complexity and size reduction can be obtained. Most of the other exchanges in TLS 1.3 are highly optimized and do not require compression to be used.¶

The compression profile defining the use of algorithms, algorithm parameters, and extensions is specified via a JSON dictionary.¶

For example, the following specialization describes a protocol with a single fixed version (TLS 1.3) and a single fixed cipher suite (TLS_AES_128_GCM_SHA256). On the wire, ClientHello.cipher_suites, ServerHello.cipher_suites, and the supported_versions extensions in the ClientHello and ServerHello would be omitted.¶

{
   "version" : 772,
   "cipherSuite" : "TLS_AES_128_GCM_SHA256"
}

The following elements are defined:¶

profile (integer):

identifies the profile being defined.¶

version (integer):

indicates that both sides agree to the single TLS version specified by the given integer value (772 == 0x0304 for TLS 1.3). The supported_versions extension is omitted from ClientHello.extensions and reconstructed in the transcript as a single-valued list with the specified value. The supported_versions extension is omitted from ClientHello.extensions and reconstructed in the transcript with the specified value.¶

cipherSuite (string):

indicates that both sides agree to the single named cipher suite, using the "TLS_AEAD_HASH" syntax defined in [RFC8446], Section 8.4. The ClientHello.cipher_suites field is omitted and reconstructed in the transcript as a single-valued list with the specified value. The server_hello.cipher_suite field is omitted and reconstructed in the transcript as the specified value.¶

dhGroup (string):

specifies a single DH group to use for key establishment. The group is listed by the code point name in [RFC8446], Section 4.2.7. (e.g., x25519). This implies a literal "supported_groups" extension consisting solely of this group.¶

signatureAlgorithm (string):

specifies a single signature scheme to use for authentication. The signature algorithm is listed by the code point name in [RFC8446], Section 4.2.3. (e.g., ecdsa_secp256r1_sha256). This implies a literal "signature_algorithms" extension consisting solely of this group.¶

random (integer):

indicates that the ClientHello.Random and ServerHello.Random values are truncated to the given length. When the transcript is reconstructed, the Random is padded to the right with 0s and the anti-downgrade mechanism in [RFC8446], Section 4.1.3 is disabled. IMPORTANT: Using short Random values can lead to potential attacks. The Random length MUST be less than or equal to 32 bytes.¶

[[Open Issue: Karthik Bhargavan suggested the idea of hashing ephemeral public keys and to use the result (truncated to 32 bytes) as random values. Such a change would require a security analysis. ]]¶

mutualAuth (boolean):

if set to true, indicates that the client must authenticate with a certificate by sending Certificate and a CertificateVerify message. The server MUST omit the CertificateRequest message, as its contents are redundant. [[OPEN ISSUE: We don't actually say that you can omit empty messages, so we need to add that somewhere.]]¶

extension_order:

indicates in what order extensions appear in respective messages. This allows to omit sending the type. If there is only a single extension to be transmitted, then the extension length field can also be omitted. For example, imagine that only the KeyShare extension needs to be sent in the ClientHello as the only extension. Then, the following structure¶

   28                    // Extensions.length
   33 26                 // KeyShare
     0024                // client_shares.length
       001d              // KeyShareEntry.group
       0020 a690...af948 // KeyShareEntry.key_exchange

is compressed down to (assuming the KeyShare group has been pre-agreed)¶

   0020 a690...af948 // KeyShareEntry.key_exchange

clientHelloExtensions (predefined extensions):

Predefined ClientHello extensions, see {predefined-extensions}¶

serverHelloExtensions (predefined extensions):

Predefined ServerHello extensions, see {predefined-extensions}¶

encryptedExtensions (predefined extensions):

Predefined EncryptedExtensions extensions, see {predefined-extensions}¶

certRequestExtensions (predefined extensions):

Predefined CertificateRequest extensions, see {predefined-extensions}¶

knownCertificates (known certificates):

A compression dictionary for the Certificate message, see {known-certs}¶

finishedSize (integer):

indicates that the Finished value is to be truncated to the given length. When the transcript is reconstructed, the remainder of the Finished value is filled in by the receiving side.¶

[[OPEN ISSUE: How short should we allow this to be? TLS 1.3 uses the native hash and TLS 1.2 used 12 bytes. More analysis is needed to know the minimum safe Finished size. See [RFC8446]; Section E.1 for more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA.]]¶

optional (object):

contains keys that are not required to be understood by the client. Server operators MUST NOT place a key in this section unless the server is able to determine whether the key is in use based on the client data it receives. A key MUST NOT appear in both the main template and the optional section.¶

{
  "00": "3082...",
  "01": "3082...",
}

2.2. Record Layer

The only cTLS records that are sent in plaintext are handshake records (ClientHello and ServerHello/HRR) and alerts. cTLS alerts are the same as TLS alerts and use the same content types. For handshake records, we set the content_type field to a fixed cTLS-specific value to distinguish cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple.¶

      struct {
          ContentType content_type = ctls_handshake;
          opaque fragment<0..2^16-1>;
      } CTLSPlaintext;

[[OPEN ISSUE: The profile_id is needed in the ClientHello to inform the server what compression profile to use. For a ServerHello this field is not required. Should we make this field optional?]]¶

Encrypted records use DTLS [I-D.draft-ietf-tls-dtls] 1.3 record framing, comprising a configuration octet followed by optional connection ID, sequence number, and length fields. The encryption process and additional data are also as described in DTLS.¶

      0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |0|0|1|C|S|L|E E|
      +-+-+-+-+-+-+-+-+
      | Connection ID |   Legend:
      | (if any,      |
      /  length as    /   C   - Connection ID (CID) present
      |  negotiated)  |   S   - Sequence number length
      +-+-+-+-+-+-+-+-+   L   - Length present
      | 8 or 16 bit   |   E   - Epoch
      |Sequence Number|
      | (if present)  |
      +-+-+-+-+-+-+-+-+
      | 16 bit Length |
      | (if present)  |
      +-+-+-+-+-+-+-+-+

      struct {
          opaque unified_hdr[variable];
          opaque encrypted_record[length];
      } CTLSCiphertext;

The presence and size of the connection ID field is negotiated as in DTLS.¶

As with DTLS, the length field MAY be omitted by clearing the L bit, which means that the record consumes the entire rest of the data in the lower level transport. In this case it is not possible to have multiple DTLSCiphertext format records without length fields in the same datagram. In stream-oriented transports (e.g., TCP), the length field MUST be present. For use over other transports length information may be inferred from the underlying layer.¶

Normal DTLS does not provide a mechanism for suppressing the sequence number field entirely. When a reliable, ordered transport (e.g., TCP) is in use, the S bit in the configuration octet MUST be cleared and the sequence number MUST be omitted. When an unreliable transport is in use, the S bit has its usual meaning and the sequence number MUST be included.¶

2.3. Handshake Layer

The cTLS handshake framing is same as the TLS 1.3 handshake framing, except for two changes:¶

• The length field is omitted.¶
• The HelloRetryRequest message is a true handshake message instead of a specialization of ServerHello.¶

      struct {
          HandshakeType msg_type;    /* handshake type */
          select (Handshake.msg_type) {
              case client_hello:          ClientHello;
              case server_hello:          ServerHello;
              case hello_retry_request:   HelloRetryRequest;
              case end_of_early_data:     EndOfEarlyData;
              case encrypted_extensions:  EncryptedExtensions;
              case certificate_request:   CertificateRequest;
              case certificate:           Certificate;
              case certificate_verify:    CertificateVerify;
              case finished:              Finished;
              case new_session_ticket:    NewSessionTicket;
              case key_update:            KeyUpdate;
          };
      } Handshake;

3.1. ClientHello

The cTLS ClientHello is defined as follows.¶

      opaque Random[RandomLength];      // variable length

      struct {
          opaque profile_id<0..2^8-1>;
          Random random;
          CipherSuite cipher_suites<1..2^16-1>;
          Extension extensions<1..2^16-1>;
      } ClientHello;

The client uses the profile_id field to inform the server about the compression profile being used (see Section 2.1). This field MUST be set to a zero-length value and only if no compression profile is used. Non zero-length values are agreed out of band between the client and server, as part of the specification of the compression profile.¶

3.2. ServerHello

We redefine ServerHello in the following way.¶

      struct {
          Random random;
          CipherSuite cipher_suite;
          Extension extensions<1..2^16-1>;
      } ServerHello;

3.3. HelloRetryRequest

The HelloRetryRequest has the following format.¶

      struct {
          CipherSuite cipher_suite;
          Extension extensions<2..2^16-1>;
      } HelloRetryRequest;

The HelloRetryRequest is the same as the ServerHello above but without the unnecessary sentinel Random value.¶

6.1. Adding a ContentType

This document requests that a code point be allocated from the "TLS ContentType registry. This value must be in the range 0-31 (inclusive). The row to be added in the registry has the following form:¶

[[ RFC EDITOR: Please replace the value TBD with the value assigned by IANA, and the value XXXX to the RFC number assigned for this document. ]]¶

[[OPEN ISSUE: Should we require standards action for all profile IDs that would fit in 2 octets.]]¶

6.2. Template Keys

This document requests that IANA open a new registry entitled "cTLS Template Keys", on the Transport Layer Security (TLS) Parameters page, with a "Specification Required" registration policy and the following initial contents:¶