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. Thus, each specialization produces a new protocol that preserves the security guarantees of TLS, but has its own unique handshake.¶

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 represented by the CTLSTemplate structure:¶

enum {
  profile(0),
  version(1),
  cipher_suite(2),
  dh_group(3),
  signature_algorithm(4),
  random(5),
  mutual_auth(6),
  handshake_framing(7),
  client_hello_extensions(8),
  server_hello_extensions(9),
  encrypted_extensions(10),
  cert_request_extensions(11),
  known_certificates(12),
  finished_size(13),
  optional(65535)
} CTLSTemplateElementType;

struct {
  CTLSTemplateElementType type;
  opaque data<0..2^32-1>;
} CTLSTemplateElement;

struct {
  uint16 ctls_version = 0;
  CTLSTemplateElement elements<0..2^32-1>
} CTLSTemplate;

• TODO: Reorder enum.¶

Elements in a CTLSTemplate MUST appear sorted by the type field in strictly ascending order. The initial elements are defined in the subsections below. Future elements can be added via an IANA registry (Section 6.2). When generating a template, all elements are OPTIONAL to include. When processing a template, all elements are mandatory to understand (but see discussion of optional in Section 2.1.1.11).¶

For ease of configuration, an equivalent JSON dictionary format is also defined. It consists of a dictionary whose keys are the name of each element type (converted from snake_case to camelCase), and whose values are a type-specific representation of the element intended to maximize legibility. The cTLS version is represented by the key "ctlsVersion", whose value is an integer, defaulting to 0 if omitted.¶

• OPEN ISSUE: Is it really worth converting snake_case to camelCase? camelCase is slightly more traditional in JSON, and saves one byte, but it seems annoying to implement.¶

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

{
  "ctlsVersion": 0,
  "profile": "0001020304050607",
  "version": 772,
  "cipherSuite": "TLS_AES_128_GCM_SHA256"
}

opaque ProfileID<1..2^8-1>

struct {
  Extension predefined_extensions<0..2^16-1>;
  ExtensionType expected_extensions<0..2^16-1>;
  uint8 allow_additional;
} CTLSExtensionTemplate;

struct {
  opaque id<1..2^8-1>;
  opaque cert_data<1..2^16-1>;
} CertificateMapEntry;

struct {
  CertificateMapEntry entries<2..2^24-1>;
} CertificateMap;

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

{
  "ctlsVersion": 0,
  "version": 772,
  "dhGroup": "x25519",
  "clientHelloExtensions": {
    "expectedExtensions": ["key_share"],
    "allowAdditional": false
  }
}

   28                 // length(extensions)
   33 26              // extension_type = KeyShare
     0024             // length(client_shares)
       001d           // KeyShareEntry.group
       0020           // length(KeyShareEntry.key_exchange)
         a690...af948 // KeyShareEntry.key_exchange

   a690...af948 // KeyShareEntry.key_exchange

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/DTLS 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 profile_id<0..2^8-1>;
          opaque fragment<0..2^16-1>;
      } CTLSClientPlaintext;

The profile_id field MUST identify the profile that is in use. A zero-length ID corresponds to the cTLS default protocol. The server's reply does not include the profile_id, because the server must be using the same profile indicated by the client.¶

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

Encrypted records use DTLS 1.3 [RFC9147] 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. cTLS Handshake Layer

The cTLS handshake is modeled in three layers:¶

1. The Transport layer¶
2. The Transcript layer¶
3. The Logical layer¶

      struct {
          HandshakeType msg_type;    /* handshake type */
          select (CTLSHandshake.msg_type) {
              case client_hello:          ClientHello;
              case server_hello:          ServerHello;
              case hello_retry_request:   HelloRetryRequest;  /* New */
              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;
              case request_connection_id: RequestConnectionId;
              case new_connection_id:     NewConnectionId;
          };
      } CTLSHandshake;

      struct {
          HandshakeType msg_type;    /* handshake type */
          uint16 message_seq;        /* DTLS-required field */
          select (CTLSDatagramHandshake.msg_type) {
            ... /* same as CTLSHandshake */
          };
      } CTLSDatagramHandshake;

3.1. ClientHello

The cTLS ClientHello is defined as follows.¶

      opaque Random[RandomLength];      // variable length

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

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

In cTLS, the HelloRetryRequest message is a true handshake message instead of a specialization of ServerHello. 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.¶

• OPEN ISSUE: Does server_hello_extensions apply to HelloRetryRequest?¶

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:¶

6.3. Adding a cTLS Template message type

IANA is requested to add the following entry to the TLS HandshakeType registry.¶

• Value: TBD¶
• Description: ctls_template¶
• DTLS-OK: ??? Not clear what to put here.¶
• Reference: (This document)¶
• Comment: Virtual message used in cTLS.¶

6.4. Activating the HelloRetryRequest MessageType

This document requests that IANA change the name of entry 6 in the TLS HandshakeType Registry from "hello_retry_request_RESERVED" to "hello_retry_request", and set its Reference field to this document.¶

6.5. Reserved profiles

This document requests that IANA open a new registry entitled "Well-known cTLS Profile IDs", on the Transport Layer Security (TLS) Parameters page, with the following columns:¶

• ID value: A sequence of 1-4 octets.¶
• Template: A JSON object.¶
• Note: An explanation or reference.¶

The ID values of length 1 are subject to a "Standards Action" registry policy. Values of length 2 are subject to an "RFC Required" policy. Values of length 3 and 4 are subject to a "First Come First Served" policy. Values longer than 4 octets are not subject to registration and MUST NOT appear in this registry.¶

The initial registry contents are:¶