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 thatare impacted differently by a compression scheme. For example, TLS supportscertificate-based authentication, raw public key-based authentication as wellas pre-shared key (PSK)-based authentication. PSK-based authentication can beused with externally configured PSKs or with PSKs established through tickets.¶

The basic idea of template-based specialization is that we start with the basicTLS 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 offreedom. For example, if we only support one version of TLS, then itis not necessary to have version negotiation and thesupported_versions extension can be omitted. Thus, each specializationproduces a new protocol that preserves the security guarantees of TLS, but hasits own unique handshake.¶

By assuming that out-of-band agreements took place already prior to the start ofthe cTLS protocol exchange, the amount of data exchanged can be radically reduced.Because different clients may use different compression templates and because multiplecompression 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. Theprofile 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 arewhere the most complexity and size reduction can be obtained. Most of the other exchanges inTLS 1.3 are highly optimized and do not require compression to be used.¶

The compression profile defining the use of algorithms, algorithm parameters, andextensions is represented by theCTLSTemplate 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 aCTLSTemplate MUST appear sorted by the type field in strictlyascending order. The initial elements are defined in the subsections below.Future elements can be added via an IANA registry (Section 6.2). Whengenerating a template, all elements are OPTIONAL to include. When processinga template, all elements are mandatory to understand (but see discussion ofoptional inSection 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 (convertedfrom snake_case to camelCase), and whose values are a type-specific representationof the element intended to maximize legibility. The cTLS version is representedby 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 fixedversion (TLS 1.3) and a single fixed cipher suite (TLS_AES_128_GCM_SHA256). On thewire, ClientHello.cipher_suites, ServerHello.cipher_suites, and thesupported_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 sameas TLS/DTLS alerts and use the same content types. For handshake records,we set thecontent_type field to a fixed cTLS-specific value todistinguish cTLS plaintext records from encrypted records, TLS/DTLSrecords, 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;

Theprofile_id field MUST identify the profile that is in use. Azero-length ID corresponds to the cTLS default protocol.The server's reply does not include theprofile_id, because the servermust 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 octetfollowed by optional connection ID, sequence number, and length fields. Theencryption 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 meansthat the record consumes the entire rest of the data in the lower leveltransport. In this case it is not possible to have multiple DTLSCiphertextformat records without length fields in the same datagram. In stream-orientedtransports (e.g., TCP), the length field MUST be present. For use over othertransports length information may be inferred from the underlying layer.¶

Normal DTLS does not provide a mechanism for suppressing the sequence numberfield entirely. When a reliable, ordered transport (e.g., TCP) is in use, theS bit in the configuration octet MUST be cleared and the sequence numberMUST be omitted. When an unreliable transport is in use, the S bithas 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 messageinstead of a specialization of ServerHello. The HelloRetryRequest hasthe following format.¶

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

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

• OPEN ISSUE: Doesserver_hello_extensions apply toHelloRetryRequest?¶

6.1.Adding a ContentType

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

• RFC EDITOR: Please replace the value TBD with the value assigned by IANA, andthe 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 TLSHandshakeType 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-knowncTLS 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" registrypolicy. Values of length 2 are subject to an "RFC Required" policy. Valuesof length 3 and 4 are subject to a "First Come First Served" policy. Valueslonger than 4 octets are not subject to registration and MUST NOT appearin this registry.¶

The initial registry contents are:¶