The Pseudorandom Extension for cTLS

2.1. Background

Compact TLS [cTLS] is a compact representation of TLS 1.3 (or later), intended for uses where compatibility with previous versions of TLS is not required. It defines a pre-configuration object called a "template" that contains a profile of the capabilities and behaviors of a TLS server, which is known to both client and server before they initiate a connection. The template allows both parties to omit information that is irrelevant or redundant, allowing a secure connection to be established while exchanging fewer bits on the wire.¶

Every cTLS template potentially results in a distinct wire image, with important implications for user privacy and ossification risk.¶

One interesting consequence of conventional wire formats (i.e. not pseudorandom) is the risk of protocol confusion attacks. For example, in the NAT Slipstreaming attacks [SLIPSTREAM], a web server causes a browser to send HTTP data that can be confused for another protocol (e.g. SIP) that is processed by a firewall. Because firewalls are typically focused on attacks arriving from outside the network, malicious payloads sent from a trusted client can trick some firewalls into disabling their own protections.¶

2.2. Goal

The goal of this extension is to enable two endpoints to agree on a TLS-based protocol whose wire image is purely pseudorandom.¶

3.1. Form

A cTLS template is structured as a JSON object. This extension is represented by an additional key, "pseudorandom", whose value is an object with at least two string-valued keys: "tsprp" (a name from the TSPRP registry (see Section 8.1)) and "key" (a base64-encoded shared secret whose length is specified by the TSPRP). For example, a cTLS template might contain an entry like:¶

"pseudorandom": {
  "tsprp": "exp-hctr2",
  "key": "nx2kEm50FCE...TyOhGOw477EHS"
},

3.2. Use

The cTLS Record Layer protocol is comprised of AEAD-encrypted ciphertext fragments interleaved with plaintext fragments. Each record is prefixed by a plaintext header, and some records, like those containing the ClientHello and ServerHello, are not encrypted at all. The ciphertext fragments are pseudorandom already, so this extension specifies a transformation of the plaintext fragments that ensures that all bits written to the wire are pseudorandom.¶

Conceptually, the extension sits between the cTLS Record Layer and the underlying transport (e.g. TCP, UDP). The transformation is based on a TSPRP with the following syntax:¶

TSPRP-Encipher(key, tweak, message) -> ciphertext
TSPRP-Decipher(key, tweak, ciphertext) -> message

The TSPRP specifies the length (in bytes) of the key. The tweak is a byte string of any length. The TSPRP uses the key and tweak to encipher the input message, which also may have any length. The output ciphertext has the same length as the input message.¶

Pseudorandom cTLS uses the TSPRP to encipher all plaintext handshake records, including the record headers. As long as there is sufficient entropy in the key_share extension or random field of the ClientHello (resp. ServerHello) the TSPRP output will be pseudorandom.¶

• TODO: Check that the assumptions hold for HelloRetryRequest. As long as no handshake messages are repeated verbatim, it should be fine, but we need to check whether an active attacker can trigger a replay.¶

Pseudorandom cTLS also enciphers every record header. In addition to the header, 16 bytes of the AEAD ciphertext itself is enciphered to ensure the input has enough entropy. Any AEAD algorithm whose ciphertext overhead is less than 16 bytes is not compatible with this specification.¶

By default, Pseudorandom cTLS assumes that the TLS ciphertext is using an AEAD algorithm whose output is purely pseudorandom, such as AES-GCM and ChaCha20-Poly1305. If the ciphertext might not be pseudorandom (e.g. when handling hostile plaintext), the ciphertext can be "reciphered" to ensure pseudorandomness (see Section 3.3).¶

client_key = TSPRP-Encipher(key, "derive", zeros)
server_key = TSPRP-Encipher(key, "derive", ones)

3.3. Protocol confusion defense

The procedure described in Section 3.2 is sufficient to render the bitstream pseudorandom to a third party when both peers are operating correctly. However, if a malicious client or server can coerce its peer into sending particular plaintext (as is common in web browsers), it can choose plaintext with knowledge of the encryption keys, in order to produce ciphertext that has visible structure to a third party. This technique can be used to mount protocol confusion attacks [SLIPSTREAM].¶

This attack is particularly straightforward when using the AES-GCM or ChaCha20-Poly1305 cipher suites, as much of the ciphertext is encrypted by XOR with a stream cipher. A malicious peer in this threat model can choose desired ciphertext, XOR it with the keystream to produce the malicious plaintext, and rely on the other peer's encryption stage to reverse the encryption and reveal the desired ciphertext.¶

As a defense against this attack, the Pseudorandom cTLS extension supports two optional keys named "client-recipher" and "server-recipher". Each key's value is an integer E between 0 and 16 (inclusive) indicating how much entropy to add. When the "client-recipher" key is present, the client MUST prepend E fresh random bytes to CTLSCiphertext.encrypted_record before encipherment. The server MUST apply a similar transformation if the "server-recipher" key is present.¶

This transformation does not alter the Length field in the Unified Header, so it does not reduce the maximum plaintext record size. However, it does increase the output message size, which may impact MTU calculations in DTLS.¶

The sender MUST compute R using a cryptographically secure pseudo-random number generator (CSPRNG) whose seed contains at least 16 bytes of entropy that is not known to the peer.¶

In general, a malicious peer can still produce desired ciphertext with probability 2^-8E for each attempt by guessing a value of R. Accordingly, values of E less than 8 are NOT RECOMMENDED for defense against confusion attacks.¶

5.1. Multiple profiles and key rotation

Pseudorandom cTLS supports multiple profiles on the same server port. If all profiles share the same Pseudorandom cTLS configuration (and the same length of connection_id if applicable), the server simply deciphers the incoming data before reading the profile_id or connection_id.¶

If multiple Pseudorandom cTLS configurations are in use, the server can use trial deciphering to determine which profile applies to each new connection. A trial is confirmed as correct if the deciphered ClientHello.profile_id matches an expected value. To avoid false matches, server operators SHOULD choose a profile_id whose length is at least 8 bytes.¶

Pseudorandom cTLS key rotation can be represented as a transition from one profile to another. If the only difference between two profiles is the Pseudorandom cTLS configuration, the server MAY use the same profile_id for both profiles, relying on trial deciphering to identify which version is in use. Trial deciphering is also sufficient to determine whether the client is using Pseudorandom cTLS, so the "pseudorandom" key MAY appear in the template's "optional" section.¶

Pseudorandom cTLS does not support demultiplexing distinct configurations by connection_id. Such use would require both the client and server to perform trial deciphering on every datagram. Instead, clients that implement Pseudorandom cTLS MUST use a distinct transport session (e.g. UDP 5-tuple) for each cTLS profile.¶

5.2. Computational cost

Pseudorandom cTLS adds a constant, symmetric computational cost to sending and receiving every record, roughly similar to the cost of encrypting a very small record. The cryptographic cost of delivering small records will therefore be increased by a constant factor, and the computational cost of delivering large records will be almost unchanged.¶

The optional defense against ciphertext confusion attacks further increases the overall computational cost, generally at least doubling the cost of delivering large records. It also adds up to 16 bytes of overhead to each encrypted record.¶

8.1. TSPRP Registry

This specification anticipates the existence of an IANA registry of Tweakable Strong Pseudorandom Permutations (TSPRPs). Until such a registry exists, the value "exp-hctr2" is reserved to indicate the HCTR2 TSPRP [HCTR2].¶

8.2. cTLS Template Key registry

This document requests that IANA add the following value to the "cTLS Template Keys" registry:¶

8.3. TLS ContentType Registry

IANA is requested to add the following codepoint to the TLS Content Types Registry¶

This document requests that a code point be allocated from the "TLS ContentType" registry. The row to be added in the registry has the following form:¶