Compact TLS 1.3

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Structure definitions listed below override TLS 1.3 definitions; any PDU not internally defined is taken from TLS 1.3.

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: ; } 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 (). 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 ). 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.

Initial template elements

TODO: Reorder section.

profile This element identifies the profile being defined. Its binary value is: ]]> This encodes the profile ID, if one is specified. IDs whose decoded length is 4 bytes or less are reserved (see ). When a reserved value is used (including the default value), other keys MUST NOT appear in the template, and a client MUST NOT accept the template unless it recognizes the ID. In JSON, the profile ID is represented as a hexadecimal-encoded string.

version Value: a single ProtocolVersion () that both parties agree to use. For TLS 1.3, the ProtocolVersion is 0x0304. When this element is included, the supported_versions extension is omitted from ClientHello.extensions. In JSON, the version is represented as an integer (772 = 0x0304 for TLS 1.3).

cipher_suite Value: a single CipherSuite () that both parties agree to use. When this element is included, the ClientHello.cipher_suites and ServerHello.cipher_suite fields are omitted. In JSON, the cipher suite is represented using the "TLS_AEAD_HASH" syntax defined in .

dh_group Value: a single NamedGroup () to use for key establishment. This is equivalent to a literal "supported_groups" extension consisting solely of this group. Static vectors (see ):

KeyShareClientHello.client_shares
KeyShareEntry.key_exchange, if the NamedGroup uses fixed-size key shares.

In JSON, the group is listed by the code point name in (e.g., "x25519").

signature_algorithm Value: a single SignatureScheme () to use for authentication. This is equivalent to a literal "signature_algorithms" extension consisting solely of this group. In JSON, the signature algorithm is listed by the code point name in . (e.g., ecdsa_secp256r1_sha256).

random Value: a single uint8. The ClientHello.Random and ServerHello.Random values are truncated to the given length. Where a 32-byte Random is required, the Random is padded to the right with 0s and the anti-downgrade mechanism in 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.

In JSON, the length is represented as an integer.

mutual_auth Value: a single uint8, with 1 representing "true" and 0 representing "false". All other values are forbidden. If set to true, this element 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.

In JSON, this value is represented as true or false.

client_hello_extensions, server_hello_extensions, encrypted_extensions, and cert_request_extensions Value: a single CTLSExtensionTemplate struct: ; ExtensionType expected_extensions<0..2^16-1>; uint8 allow_additional; } CTLSExtensionTemplate; ]]> The predefined_extensions field indicates extensions that should be treated as if they were included in the corresponding message. This allows these extensions to be omitted entirely. The expected_extensions field indicates extensions that must be included in the corresponding message, at the beginning of its extensions field. The types of these extensions are omitted when serializing the extensions field of the corresponding message. The allow_additional field MUST be 0 (false) or 1 (true), indicating whether additional extensions are allowed here. predefined_extensions and expected_extensions MUST be in strictly ascending order by ExtensionType, and a single ExtensionType MUST NOT appear in both lists. If the version, dh_group, or signature_algorithm element appears in the template, the corresponding ExtensionType MUST NOT appear here.

OPEN ISSUE: Are there other extensions that would benefit from special treatment, as opposed to hex values.

Static vectors (see ):

Extension.extension_data for any extension in expected_extensions whose value has fixed length. This applies only to the corresponding message.
The extensions field of the corresponding message, if allow_additional is false.

In JSON, this value is represented as a dictionary with three keys:

predefinedExtensions: a dictionary mapping ExtensionType names () to values encoded as hexadecimal strings.
expectedExtensions: an array of ExtensionType names.
allowAdditional: true or false.

If predefinedExtensions or expectedExtensions is empty, it MAY be omitted.

OPEN ISSUE: Should we have a certificate_entry_extensions element?

finished_size Value: uint8, indicating that the Finished value is to be truncated to the given length.

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 for more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA.

In JSON, this length is represented as an integer.

handshake_framing Value: uint8, with 0 indicating "false" and 1 indicating "true". If true, handshake messages MUST be conveyed inside a Handshake () struct on stream transports, or a DTLSHandshake () struct on datagram transports, and MAY be broken into multiple records as in TLS and DTLS. Otherwise, each handshake message is conveyed in a CTLSHandshake or CTLSDatagramHandshake struct (), which MUST be the payload of a single record. In JSON, this value is represented as true or false.

optional Value: a CTLSTemplate containing elements that are not required to be understood by the client. Server operators MUST NOT place an element in this section unless the server is able to determine whether the client is using it from the client data it receives. A key MUST NOT appear in both the main template and the optional section. In JSON, this value is represented in the same way as the CTLSTemplate itself.

known_certificates Value: a CertificateMap struct: ; opaque cert_data<1..2^16-1>; } CertificateMapEntry; struct { CertificateMapEntry entries<2..2^24-1>; } CertificateMap; ]]> Entries in the certificate map must appear in strictly ascending lexicographic order by ID. In JSON, CertificateMap is represented as a dictionary from id to cert_data, which are both represented as hexademical strings: Certificates are a major contributor to the size of a TLS handshake. In order to avoid this overhead when the parties to a handshake have already exchanged certificates, a compression profile can specify a dictionary of "known certificates" that effectively acts as a compression dictionary on certificates. When compressing a Certificate message, the sender examines the cert_data field of each CertificateEntry. If the cert_data matches a value in the known certificates object, then the sender replaces the cert_data with the corresponding key. Decompression works the opposite way, replacing keys with values. Note that in this scheme, there is no signaling on the wire for whether a given cert_data value is compressed or uncompressed. Known certificates objects SHOULD be constructed in such a way as to avoid a uncompressed object being mistaken for compressed one and erroneously decompressed. For X.509, it is sufficient for the first byte of the compressed value (key) to have a value other than 0x30, since every X.509 certificate starts with this byte.

Static vector compression Some cTLS template elements imply that certain vectors (as defined in ) have a fixed number of elements during the handshake. These template elements note these "static vectors" in their definition. When encoding a "static vector", its length prefix is omitted. For example, suppose that the cTLS template is: Then, the following structure: is compressed down to: according to the following rationale:

The length of extensions is omitted because allowAdditional is false, so the number of items in extensions (i.e., 1) is known in advance.
extension_type is omitted because it is specified by expected_extensions.
The length of client_shares is omitted because the use of dhGroup implies that there can only be one KeyShareEntry.
KeyShareEntry.group is omitted because it is specified by dhGroup.
The length of the key_exchange is omitted because the "x25519" key share has a fixed size (32 bytes).

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. ; 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. ; } CTLSServerPlaintext; ]]> Encrypted records use 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. 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.

cTLS Handshake Layer The cTLS handshake is modeled in three layers:

The Transport layer
The Transcript layer
The Logical layer

The Transport layer When template.handshake_framing is false, the cTLS transport layer uses a custom handshake framing that saves space by relying on the record layer for message lengths. (This saves 3 bytes per message compared to TLS, or 9 bytes compared to DTLS.) This compact framing is defined by the CTLSHandshake and CTLSDatagramHandshake structs. Any handshake type registered in the IANA TLS HandshakeType Registry can be conveyed in a CTLS[Datagram]Handshake, but not all messages are actually allowed on a given connection. This definition shows the messages types supported in CTLSHandshake as of TLS 1.3 and DTLS 1.3, but any future message types are also permitted. Each CTLSHandshake or CTLSDatagramHandshake MUST be conveyed as a single CTLSClientPlaintext.fragment, CTLSServerPlaintext.fragment, or CTLSCiphertext.encrypted_record, and is therefore limited to a maximum length of 2^16-1 or less. When operating over UDP, large CTLSDatagramHandshake messages will also require the use of IP fragmentation, which is sometimes undesirable. Operators can avoid these concerns by setting template.handshakeFraming = true.

The Transcript layer TLS and DTLS start the handshake with an empty transcript. cTLS is different: it starts the transcript with a "virtual message" whose HandshakeType is ctls_template () containing the CTLSTemplate used for this connection. This message is included in the transcript even though it is not exchanged during connection setup, in order to ensure that both parties are using the same template. Subsequent messages are appended to the transcript as usual. When computing the handshake transcript, all handshake messages are represented in TLS Handshake messages, as in DTLS 1.3 (), regardless of template.handshake_framing. To ensure that all parties agree about what protocol is in use, the Cryptographic Label Prefix used for the handshake SHALL be "Sctls " for Stream cTLS and "Dctls " for Datagram cTLS. (This is similar to the prefix substitution in ).

The Logical layer The logical handshake layer consists of handshake messages that are reconstructed following the instructions in the template. At this layer, predefined extensions are reintroduced, truncated Random values are extended, and all information is prepared to enable the cryptographic handshake and any import or export of key material and configuration. There is no obligation to reconstruct logical handshake messages in any specific format, and client and server do not need to agree on the precise representation of these messages, so long as they agree on their logical contents.

Value	Description	DTLS-OK	Reference
TBD	ctls	Y	RFCXXXX
TBD	ctls_handshake	Y	RFCXXXX

Name	Value	Reference
profile	0	(This document)
version	1	(This document)
cipher_suite	2	(This document)
dh_group	3	(This document)
signature_algorithm	4	(This document)
random	5	(This document)
mutual_auth	6	(This document)
handshake_framing	7	(This document)
client_hello_extensions	8	(This document)
server_hello_extensions	9	(This document)
encrypted_extensions	10	(This document)
cert_request_extensions	11	(This document)
known_certificates	12	(This document)
finished_size	13	(This document)
optional	65535	(This document)