The Pseudorandom Extension for cTLS
draft-cpbs-pseudorandom-ctls-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Benjamin M. Schwartz , Christopher Patton | ||
| Last updated | 2021-10-25 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-cpbs-pseudorandom-ctls-00
TLS WG B. Schwartz
Internet-Draft Google LLC
Intended status: Experimental C. Patton
Expires: 28 April 2022 Cloudflare, Inc.
25 October 2021
The Pseudorandom Extension for cTLS
draft-cpbs-pseudorandom-ctls-00
Abstract
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
https://github.com/bemasc/pseudorandom-ctls.
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 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 Notice
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
Schwartz & Patton Expires 28 April 2022 [Page 1]
Internet-Draft Pseudorandom cTLS October 2021
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.
Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1. Requirements . . . . . . . . . . . . . . . . . . . . 3
2.2.2. Non-requirements . . . . . . . . . . . . . . . . . . 3
3. The Pseudorandom Extension . . . . . . . . . . . . . . . . . 4
3.1. Form . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. With Streaming Transports . . . . . . . . . . . . . . 5
3.2.2. With Datagram Transports . . . . . . . . . . . . . . 6
4. Plaintext Alerts . . . . . . . . . . . . . . . . . . . . . . 7
5. Operational Considerations . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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
Schwartz & Patton Expires 28 April 2022 [Page 2]
Internet-Draft Pseudorandom cTLS October 2021
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.
Schwartz & Patton Expires 28 April 2022 [Page 3]
Internet-Draft Pseudorandom cTLS October 2021
* 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.
Schwartz & Patton Expires 28 April 2022 [Page 4]
Internet-Draft Pseudorandom cTLS October 2021
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:
Schwartz & Patton Expires 28 April 2022 [Page 5]
Internet-Draft Pseudorandom cTLS October 2021
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
Schwartz & Patton Expires 28 April 2022 [Page 6]
Internet-Draft Pseudorandom cTLS October 2021
* 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.
Schwartz & Patton Expires 28 April 2022 [Page 7]
Internet-Draft Pseudorandom cTLS October 2021
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?
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.
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?
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.
Schwartz & Patton Expires 28 April 2022 [Page 8]
Internet-Draft Pseudorandom cTLS October 2021
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).
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
[cTLS] Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
ctls-04, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
ctls-04>.
Schwartz & Patton Expires 28 April 2022 [Page 9]
Internet-Draft Pseudorandom cTLS October 2021
[DTLS13] 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, 30 April 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
dtls13-43>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/rfc/rfc5116>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
9.2. Informative References
[SLIPSTREAM]
"NAT Slipstreaming v2.0", n.d.,
<https://samy.pl/slipstream/>.
Acknowledgments
TODO
Authors' Addresses
Benjamin Schwartz
Google LLC
Email: bemasc@google.com
Christopher Patton
Cloudflare, Inc.
Email: cpatton@cloudflare.com
Schwartz & Patton Expires 28 April 2022 [Page 10]