| Internet-Draft | Pseudorandom cTLS | October 2021 |
| Schwartz & Patton | Expires 28 April 2022 | [Page] |
This draft describes a cTLS extension that allows each party to emit a purely pseudorandom bitstream.¶
This note is to be removed before publishing as an RFC.¶
Source for this draft and an issue tracker can be found at https://github.com/bemasc/pseudorandom-ctls.¶
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 https://datatracker.ietf.org/drafts/current/.¶
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.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
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.¶
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.¶
The goal of this extension is to enable two endpoints to agree on a TLS-based protocol whose wire image is purely pseudorandom.¶
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.¶
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.¶
When used over a streaming transport, Pseudorandom cTLS requires that headers have predictable lengths. This creates the following limitations:¶
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:¶
The sender first constructs any CTLSPlaintext records as follows:¶
tweak = "client hs" + profile_id if sent by the client, or "server hs" + profile_id if sent by the server.¶
STPRP-Encipher(key, tweak, message).¶
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:¶
hdr_length be the length of the record header (normally 3 for CTLSCiphertext or 4 for CTLSPlaintext).¶
prefix be the first hdr_length + 16 bytes of the record.¶
tweak = "client" if sent by the client, or "server" if sent by the server.¶
tweak.¶
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?¶
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:¶
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.¶
index = 0.¶
While index != len(payload):¶
prefix = payload[index : min(len(payload), index + max_hdr_length + 16)]¶
tweak = "client datagram" + len(payload) + index if sent by the client, or "server datagram" + len(payload) + index if sent by the server.¶
prefix with STPRP-Decipher(key, tweak, prefix).¶
index to the end of this record.¶
CTLSPlaintext records are subject to an additional decipherment step:¶
Handshake.body (Section 5.5 of [DTLS13]).¶
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.¶
Handshake.body with STPRP-Decipher(key, tweak, Handshake.body).¶
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.¶
QUESTION: Are there client-issued Alerts in response to malformed ServerHello?¶
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.¶
TODO: Key rotation. How does it work? We could possibly use trial decryption, with parsing and profile-id matching as an implicit MAC, but it feels a bit soft. Does it help if we put a "key ID" in the tweak?¶
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.¶
TODO: More precise security properties and security proof. The goal we're after hasn't been widely considered in the literature so far, at least as far as we can tell. The basic idea is that the "real" protocol (Pseudorandom cTLS) should be indistinguishable from some "target" protocol that the network is known tolerate. The assumption is that middleboxes would not attempt to parse packets whose contents are pseudorandom. (The same idea underlies QUIC's wire encoding format [RFC9000].) A starting point might be the formal notion of "Observational Equivalence" (https://infsec.ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/information-security-group-dam/research/publications/pub2015/ASPObsEq.pdf).¶
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.¶
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.¶
TODO¶