Internet-Draft Pseudorandom cTLS October 2021
Schwartz & Patton Expires 28 April 2022 [Page]
Intended Status:
B. Schwartz
Google LLC
C. Patton
Cloudflare, Inc.

The Pseudorandom Extension for cTLS


This draft describes a cTLS extension that allows each party to emit a purely pseudorandom bitstream.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 28 April 2022.

Table of Contents

1. Conventions and Definitions

The contents of a two-party protocol as perceived by a third party are called the "wire image".

A Strong Tweakable Pseudorandom Permutation (STPRP) is a variable-input-length block cipher that accepts a high-entropy "key" and low-entropy "tweak".

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Introduction

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.

2.2.1. Requirements

  • Protocol confusion attack resistance: Neither party has any influence over the bytes emitted by the other party.
  • Privacy: A third party without access to the template cannot tell whether two connections are using the same pseudorandom cTLS template, or two different pseudorandom cTLS templates.
  • Ossification risk: Every byte sent on the underlying transport is pseudorandom to an observer who does not know the cTLS template.
  • Efficiency: Zero size overhead and minimal CPU cost. Support for servers with many cTLS templates, when appropriately constructed.

2.2.2. Non-requirements

  • Efficient support for demultiplexing arbitrary cTLS templates.
  • Addressing information leakage in the length and timing of transmissions.

3. The Pseudorandom Extension

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 two string-valued keys: "stprp" (a name from the STPRP registry (see Section 8)) and "key" (a base64-encoded shared secret whose length is specified by the STPRP). For example, a cTLS template might contain an entry like:

"pseudorandom": {
  "stprp": "aes-128-cbc-mask-cbc",
  "key": "nx2kEm50FCE...TyOhGOw477EHS"
  • TODO: Talk about compatibility. Pseudorandom isn't backwards-compatible. Is there even such a thing as a "cTLS extension"?

  • TODO: Consider having two keys, one for sending data from client to server and another for sending data from server to client, to align better with the TLS key schedule. These could be specified explicitly or generated from a single secret by a KDF.

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 an STPRP with the following syntax:

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

The STPRP specifies the length (in bytes) of the key. The tweak is a byte string of any length. The STPRP 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.

The Pseudorandom cTLS design assumes that the negotiated AEAD algorithm produces pseudorandom ciphertexts. This is not a requirement of the AEAD specification [RFC5116], but it is true of popular AEAD algorithms like AES-GCM and ChaCha20-Poly1305.

Pseudorandom cTLS uses the STPRP 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 STPRP 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. All currently registered AEAD algorithms produce at least this much ciphertext from any input. Any AEAD algorithm that can produce smaller ciphertexts is not compatible with this specification.

3.2.1. With Streaming Transports

When used over a streaming transport, Pseudorandom cTLS requires that headers have predictable lengths. This creates the following limitations:

  • If a Connection ID is negotiated, it MUST always be included.
  • If the Sequence Number is not suppressed in the template, it MUST always have 16-bit length.

Normally, when TLS runs on top of a streaming transport, Connection IDs are not enabled and Sequence Numbers are omitted, so this is not expected to be a significant limitation.

The transformation performed by the sender takes the following inputs:

  • STPRP-Encipher() and key from template.pseudorandom
  • template.profile_id from the cTLS template

The sender first constructs any CTLSPlaintext records as follows:

  1. Set tweak = "client hs" + profile_id if sent by the client, or "server hs" + profile_id if sent by the server.
  2. Replace the message with STPRP-Encipher(key, tweak, message).
  3. Fragment the message if necessary, ensuring at least 16 bytes of message in each fragment.
  4. Change the content_type of the final fragment to ctls_handshake_end(TBD).

Note: This procedure assumes that handshake messages are at least 16 bytes long. This condition is automatically true in most configurations.

The sender then constructs cTLS records as usual, but applies the following transformation before sending each record:

  1. Let hdr_length be the length of the record header (normally 3 for CTLSCiphertext or 4 for CTLSPlaintext).
  2. Let prefix be the first hdr_length + 16 bytes of the record.
  3. Set tweak = "client" if sent by the client, or "server" if sent by the server.
  4. If the record is CTLSCiphertext, append the 64-bit Sequence Number to tweak.
  5. Replace prefix with STPRP-Encipher(key, tweak, prefix).
  • OPEN ISSUE: How should we actually form the tweaks? Can we assume arbitrary length? Should we add some kind of chaining, within a stream or binding ServerHello to ClientHello?

3.2.2. With Datagram Transports

Pseudorandom cTLS applies to datagram applications of cTLS without restriction. If there are multiple records in the datagram, encipherment starts with the last record header and proceeds back-to-front.

Given the inputs:

  • payload, an entire datagram that may contain multiple cTLS records.
  • STPRP-Decipher() and key from template.pseudorandom
  • template.profile_id
  • connection_id, the ID expected on incoming CTLSCiphertext records

The recipient deciphers the datagram as follows:

  1. Let max_hdr_length = max(16, len(connection_id) + 5). This represents the most data that might be needed to read the DTLS Handshake header (Section 5.2 of [DTLS13]) or the CTLSCiphertext header.
  2. Let index = 0.
  3. While index != len(payload):

    1. Let prefix = payload[index : min(len(payload), index + max_hdr_length + 16)]
    2. Let tweak = "client datagram" + len(payload) + index if sent by the client, or "server datagram" + len(payload) + index if sent by the server.
    3. Replace prefix with STPRP-Decipher(key, tweak, prefix).
    4. Set index to the end of this record.

CTLSPlaintext records are subject to an additional decipherment step:

  1. Perform fragment reassembly to recover the complete Handshake.body (Section 5.5 of [DTLS13]).
  2. Let tweak be "client datagram hs" + profile_id + Handshake.msg_type if sent by the client, or "server datagram hs" + profile_id + Handshake.msg_type if sent by the server.
  3. Replace Handshake.body with STPRP-Decipher(key, tweak, Handshake.body).

4. Plaintext Alerts

Representing plaintext alerts (i.e. CTLSPlaintext messages with content_type = alert(TBD)) requires additional steps, because Alert fragments have little entropy.

A standard TLS Alert fragment is always 2 bytes long. In Pseudorandom cTLS, senders MUST append at least 16 random bytes to any plaintext Alert fragment. Enciphering and deciphering then proceed identically to other CTLSPlaintext messages. The recipient MUST remove these bytes before passing the CTLSPlaintext to the cTLS implementation.

Servers SHOULD expand any Alert message following the ClientHello to the same size as their usual ServerHello, and SHOULD send additional random TCP segments or datagrams to match the sizes of subsequent components of their ordinary success response. Otherwise, an adversary could use probing to learn the allowed lengths of ClientHellos and the fraction of ciphertexts that decipher to valid ClientHellos.

5. Operational Considerations

Pseudorandom cTLS can interfere with the use of multiple profiles on a single server. To use Pseudorandom cTLS with multiple profiles, servers must use the same STPRP key and the same lengths of connection_id.

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.

6. Security Considerations

Pseudorandom cTLS operates as a layer between cTLS and its transport, so the security properties of cTLS are largely preserved. However, there are some small differences.

In datagram mode, the profile_id and connection_id fields allow a server to reject almost all packets from a sender who does not know the template (e.g. a DDoS attacker), with minimal CPU cost. Pseudorandom cTLS requires the server to apply a decryption operation to every incoming datagram before establishing whether it might be valid. This operation is O(1) and uses only symmetric cryptography, so the impact is expected to be bearable in most deployments.

7. Privacy Considerations

Pseudorandom cTLS is intended to improve privacy in scenarios where the adversary lacks access to the cTLS template. However, if the adversary does have access to the cTLS template, and the template does not have a distinctive profile_id, Pseudorandom cTLS can reduce privacy, by enabling strong confirmation that a connection is indeed using that template.

8. IANA Considerations

We assume the existence of an IANA registry of Strong Tweakable Pseudorandom Permutations (STPRPs). However, no such registry exists at present. This draft is blocked until someone documents and registers a suitable STPRP algorithm.

9. References

9.1. Normative References

Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-ctls-04, , <>.
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-dtls13-43, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <>.

9.2. Informative References

"NAT Slipstreaming v2.0", n.d., <>.



Authors' Addresses

Benjamin Schwartz
Google LLC
Christopher Patton
Cloudflare, Inc.