idnits 2.17.00 (12 Aug 2021) /tmp/idnits41354/draft-cpbs-pseudorandom-ctls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (11 April 2022) is 33 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS WG B. Schwartz 3 Internet-Draft Google LLC 4 Intended status: Experimental C. Patton 5 Expires: 13 October 2022 Cloudflare, Inc. 6 11 April 2022 8 The Pseudorandom Extension for cTLS 9 draft-cpbs-pseudorandom-ctls-01 11 Abstract 13 This draft describes a cTLS extension that allows each party to emit 14 a purely pseudorandom bitstream. 16 Discussion Venues 18 This note is to be removed before publishing as an RFC. 20 Source for this draft and an issue tracker can be found at 21 https://github.com/bemasc/pseudorandom-ctls. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 13 October 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2.1. Requirements . . . . . . . . . . . . . . . . . . . . 3 61 2.2.2. Non-requirements . . . . . . . . . . . . . . . . . . 4 62 2.2.3. Experimental status . . . . . . . . . . . . . . . . . 4 63 3. The Pseudorandom Extension . . . . . . . . . . . . . . . . . 4 64 3.1. Form . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2.1. Key Derivation . . . . . . . . . . . . . . . . . . . 6 67 3.2.2. With Streaming Transports . . . . . . . . . . . . . . 6 68 3.2.3. With Datagram Transports . . . . . . . . . . . . . . 7 69 3.3. Protocol confusion defense . . . . . . . . . . . . . . . 8 70 4. Plaintext Alerts . . . . . . . . . . . . . . . . . . . . . . 9 71 5. Operational Considerations . . . . . . . . . . . . . . . . . 9 72 5.1. Multiple profiles and key rotation . . . . . . . . . . . 9 73 5.2. Computational cost . . . . . . . . . . . . . . . . . . . 10 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 8.1. TSPRP Registry . . . . . . . . . . . . . . . . . . . . . 11 78 8.2. cTLS Template Key registry . . . . . . . . . . . . . . . 11 79 8.3. TLS ContentType Registry . . . . . . . . . . . . . . . . 12 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 9.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Conventions and Definitions 88 The contents of a two-party protocol as perceived by a third party 89 are called the "wire image". 91 A Tweakable Strong Pseudorandom Permutation (TSPRP) is a variable- 92 input-length block cipher that is parameterized by a secret "key" and 93 a public "tweak". Also known as a "super-pseudorandom permutation" 94 or "wide block cipher". 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in 99 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 2. Introduction 104 2.1. Background 106 Compact TLS [cTLS] is a compact representation of TLS 1.3 (or later), 107 intended for uses where compatibility with previous versions of TLS 108 is not required. It defines a pre-configuration object called a 109 "template" that contains a profile of the capabilities and behaviors 110 of a TLS server, which is known to both client and server before they 111 initiate a connection. The template allows both parties to omit 112 information that is irrelevant or redundant, allowing a secure 113 connection to be established while exchanging fewer bits on the wire. 115 Every cTLS template potentially results in a distinct wire image, 116 with important implications for user privacy and ossification risk. 118 One interesting consequence of conventional wire formats (i.e. not 119 pseudorandom) is the risk of protocol confusion attacks. For 120 example, in the NAT Slipstreaming attacks [SLIPSTREAM], a web server 121 causes a browser to send HTTP data that can be confused for another 122 protocol (e.g. SIP) that is processed by a firewall. Because 123 firewalls are typically focused on attacks arriving from outside the 124 network, malicious payloads sent from a trusted client can trick some 125 firewalls into disabling their own protections. 127 2.2. Goal 129 The goal of this extension is to enable two endpoints to agree on a 130 TLS-based protocol whose wire image is purely pseudorandom. 132 2.2.1. Requirements 134 * Privacy: A third party without access to the template cannot tell 135 whether two connections are using the same pseudorandom cTLS 136 template, or two different pseudorandom cTLS templates. 138 * Ossification risk: Every byte sent on the underlying transport is 139 pseudorandom to an observer who does not know the cTLS template. 141 * Efficiency: Zero size overhead and minimal CPU cost in the 142 simplest case. Support for servers with many cTLS templates, when 143 appropriately constructed. 145 * Protocol confusion attack resistance: This attack assumes a 146 malicious server or client that can coerce its peer into sending a 147 ciphertext that could be misinterpreted as a different protocol by 148 a third party. This extension must enable each peer to ensure 149 that its own output is unlikely to resemble any other protocol. 151 2.2.2. Non-requirements 153 * Efficient support for demultiplexing arbitrary cTLS templates. 155 * Addressing information leakage in the length and timing of 156 transmissions. 158 2.2.3. Experimental status 160 This specification has experimental status (INTENDED). The goals of 161 this experiment include: 163 * To assess the internet's tolerance of unrecognized protocols. 165 * To gain experience with TSPRPs in a protocol context. 167 * To exercise cTLS's extensibility features. 169 * To support practical and theoretical research into protocol 170 distinguishability. 172 3. The Pseudorandom Extension 174 3.1. Form 176 A cTLS template is structured as a JSON object. This extension is 177 represented by an additional key, "pseudorandom", whose value is an 178 object with at least two string-valued keys: "tsprp" (a name from the 179 TSPRP registry (see Section 8.1)) and "key" (a base64-encoded shared 180 secret whose length is specified by the TSPRP). For example, a cTLS 181 template might contain an entry like: 183 "pseudorandom": { 184 "tsprp": "exp-hctr2", 185 "key": "nx2kEm50FCE...TyOhGOw477EHS" 186 }, 188 3.2. Use 190 The cTLS Record Layer protocol is comprised of AEAD-encrypted 191 ciphertext fragments interleaved with plaintext fragments. Each 192 record is prefixed by a plaintext header, and some records, like 193 those containing the ClientHello and ServerHello, are not encrypted 194 at all. The ciphertext fragments are pseudorandom already, so this 195 extension specifies a transformation of the plaintext fragments that 196 ensures that all bits written to the wire are pseudorandom. 198 Conceptually, the extension sits between the cTLS Record Layer and 199 the underlying transport (e.g. TCP, UDP). The transformation is 200 based on a TSPRP with the following syntax: 202 TSPRP-Encipher(key, tweak, message) -> ciphertext 203 TSPRP-Decipher(key, tweak, ciphertext) -> message 205 The TSPRP specifies the length (in bytes) of the key. The tweak is a 206 byte string of any length. The TSPRP uses the key and tweak to 207 encipher the input message, which also may have any length. The 208 output ciphertext has the same length as the input message. 210 Pseudorandom cTLS uses the TSPRP to encipher all plaintext handshake 211 records, including the record headers. As long as there is 212 sufficient entropy in the key_share extension or random field of the 213 ClientHello (resp. ServerHello) the TSPRP output will be 214 pseudorandom. 216 TODO: Check that the assumptions hold for HelloRetryRequest. As 217 long as no handshake messages are repeated verbatim, it should be 218 fine, but we need to check whether an active attacker can trigger 219 a replay. 221 Pseudorandom cTLS also enciphers every record header. In addition to 222 the header, 16 bytes of the AEAD ciphertext itself is enciphered to 223 ensure the input has enough entropy. Any AEAD algorithm whose 224 ciphertext overhead is less than 16 bytes is not compatible with this 225 specification. 227 By default, Pseudorandom cTLS assumes that the TLS ciphertext is 228 using an AEAD algorithm whose output is purely pseudorandom, such as 229 AES-GCM and ChaCha20-Poly1305. If the ciphertext might not be 230 pseudorandom (e.g. when handling hostile plaintext), the ciphertext 231 can be "reciphered" to ensure pseudorandomness (see Section 3.3). 233 3.2.1. Key Derivation 235 To provide clear separation between data sent by the client and the 236 server, the client and server encipher data using different keys, 237 derived from the profile key as follows: 239 client_key = TSPRP-Encipher(key, "derive", zeros) 240 server_key = TSPRP-Encipher(key, "derive", ones) 242 where zeros and ones are messages the same size as key, with all bits 243 set to zero and one respectively. This procedure guarantees that 244 client_key and server_key are distinct and would appear unrelated to 245 any party who does not know the profile key. 247 3.2.2. With Streaming Transports 249 When used over a streaming transport, Pseudorandom cTLS requires that 250 headers have predictable lengths. Therefore, if a Connection ID is 251 negotiated, it MUST always be included. Normally, when TLS runs on 252 top of a streaming transport, Connection IDs are not enabled, so this 253 is not expected to be a significant limitation. 255 The transformation performed by the sender uses TSPRP-Encipher() and 256 client_key or server_key. The sender first constructs any 257 CTLSPlaintext records as follows: 259 1. Set tweak = "hs". 261 2. Replace the message with TSPRP-Encipher(client/server_key, tweak, 262 message). 264 3. Fragment the message if necessary, ensuring each fragment is at 265 least 16 bytes long. 267 4. Change the content_type of the final fragment to 268 ctls_handshake_end(TBD) (see Section 8.3). 270 Note: This procedure requires that handshake messages are at least 16 271 bytes long. This condition is automatically true in most 272 configurations. 274 The sender then constructs cTLS records as usual, but applies the 275 following transformation before sending each record: 277 1. Let prefix be the first 19 bytes of the record. 279 2. If the record is CTLSPlaintext, set tweak = "". 281 3. If the record is CTLSCiphertext, let tweak be the 64-bit Sequence 282 Number in network byte order. 284 4. Replace prefix with TSPRP-Encipher(client/server_key, tweak, 285 prefix). 287 OPEN ISSUE: How should we actually form the tweaks? Should we add 288 some kind of chaining, within a stream or binding ServerHello to 289 ClientHello? 291 3.2.3. With Datagram Transports 293 Pseudorandom cTLS applies to datagram applications of cTLS without 294 restriction. If there are multiple records in the datagram, 295 encipherment starts with the last record header and proceeds back-to- 296 front. 298 Given the inputs: 300 * payload, an entire datagram that may contain multiple cTLS 301 records. 303 * TSPRP-Decipher() and client_key or server_key 305 * connection_id, the ID expected on incoming CTLSCiphertext records 307 The recipient deciphers the datagram as follows: 309 1. Let max_hdr_length = max(15, len(connection_id) + 5). This 310 represents the most data that might be needed to read the 311 CTLSPlaintext and DTLS Handshake headers (Section 5.2 of 312 [DTLS13]) or the CTLSCiphertext header. 314 2. Let index = 0. 316 3. While index != len(payload): 318 1. Let prefix = payload[index : min(len(payload), index + 319 max_hdr_length + 16)] 321 2. Let tweak = "datagram" + len(payload) + index. 323 3. Replace prefix with TSPRP-Decipher(client/server_key, tweak, 324 prefix). 326 4. Set index to the end of this record. 328 CTLSPlaintext records are subject to an additional decipherment step: 330 1. Perform fragment reassembly to recover the complete 331 Handshake.body (Section 5.5 of [DTLS13]). 333 2. Let tweak be "datagram hs" + Handshake.msg_type. 335 3. Replace Handshake.body with TSPRP-Decipher(client/server_key, 336 tweak, Handshake.body). 338 3.3. Protocol confusion defense 340 The procedure described in Section 3.2 is sufficient to render the 341 bitstream pseudorandom to a third party when both peers are operating 342 correctly. However, if a malicious client or server can coerce its 343 peer into sending particular plaintext (as is common in web 344 browsers), it can choose plaintext with knowledge of the encryption 345 keys, in order to produce ciphertext that has visible structure to a 346 third party. This technique can be used to mount protocol confusion 347 attacks [SLIPSTREAM]. 349 This attack is particularly straightforward when using the AES-GCM or 350 ChaCha20-Poly1305 cipher suites, as much of the ciphertext is 351 encrypted by XOR with a stream cipher. A malicious peer in this 352 threat model can choose desired ciphertext, XOR it with the keystream 353 to produce the malicious plaintext, and rely on the other peer's 354 encryption stage to reverse the encryption and reveal the desired 355 ciphertext. 357 As a defense against this attack, the Pseudorandom cTLS extension 358 supports two optional keys named "client-recipher" and "server- 359 recipher". Each key's value is an integer E between 0 and 16 360 (inclusive) indicating how much entropy to add. When the "client- 361 recipher" key is present, the client MUST prepend E fresh random 362 bytes to CTLSCiphertext.encrypted_record before encipherment. The 363 server MUST apply a similar transformation if the "server-recipher" 364 key is present. 366 This transformation does not alter the Length field in the Unified 367 Header, so it does not reduce the maximum plaintext record size. 368 However, it does increase the output message size, which may impact 369 MTU calculations in DTLS. 371 The sender MUST compute R using a cryptographically secure pseudo- 372 random number generator (CSPRNG) whose seed contains at least 16 373 bytes of entropy that is not known to the peer. 375 In general, a malicious peer can still produce desired ciphertext 376 with probability 2^-8E for each attempt by guessing a value of R. 377 Accordingly, values of E less than 8 are NOT RECOMMENDED for defense 378 against confusion attacks. 380 4. Plaintext Alerts 382 Representing plaintext alerts (i.e. CTLSPlaintext messages with 383 content_type = alert(21)) requires additional steps, because Alert 384 fragments have little entropy. 386 A standard TLS Alert fragment is always 2 bytes long. In 387 Pseudorandom cTLS, senders MUST append at least 16 random bytes to 388 any plaintext Alert fragment and increase CTLSPlaintext.length 389 accordingly. Enciphering and deciphering then proceed identically to 390 other CTLSPlaintext messages. The recipient MUST remove these bytes 391 before passing the CTLSPlaintext to the cTLS implementation. 393 QUESTION: Are there client-issued Alerts in response to malformed 394 ServerHello? 396 5. Operational Considerations 398 5.1. Multiple profiles and key rotation 400 Pseudorandom cTLS supports multiple profiles on the same server port. 401 If all profiles share the same Pseudorandom cTLS configuration (and 402 the same length of connection_id if applicable), the server simply 403 deciphers the incoming data before reading the profile_id or 404 connection_id. 406 If multiple Pseudorandom cTLS configurations are in use, the server 407 can use trial deciphering to determine which profile applies to each 408 new connection. A trial is confirmed as correct if the deciphered 409 ClientHello.profile_id matches an expected value. To avoid false 410 matches, server operators SHOULD choose a profile_id whose length is 411 at least 8 bytes. 413 Pseudorandom cTLS key rotation can be represented as a transition 414 from one profile to another. If the only difference between two 415 profiles is the Pseudorandom cTLS configuration, the server MAY use 416 the same profile_id for both profiles, relying on trial deciphering 417 to identify which version is in use. Trial deciphering is also 418 sufficient to determine whether the client is using Pseudorandom 419 cTLS, so the "pseudorandom" key MAY appear in the template's 420 "optional" section. 422 Pseudorandom cTLS does not support demultiplexing distinct 423 configurations by connection_id. Such use would require both the 424 client and server to perform trial deciphering on every datagram. 425 Instead, clients that implement Pseudorandom cTLS MUST use a distinct 426 transport session (e.g. UDP 5-tuple) for each cTLS profile. 428 5.2. Computational cost 430 Pseudorandom cTLS adds a constant, symmetric computational cost to 431 sending and receiving every record, roughly similar to the cost of 432 encrypting a very small record. The cryptographic cost of delivering 433 small records will therefore be increased by a constant factor, and 434 the computational cost of delivering large records will be almost 435 unchanged. 437 The optional defense against ciphertext confusion attacks further 438 increases the overall computational cost, generally at least doubling 439 the cost of delivering large records. It also adds up to 16 bytes of 440 overhead to each encrypted record. 442 6. Security Considerations 444 Pseudorandom cTLS operates as a layer between cTLS and its transport, 445 so the security properties of cTLS are largely preserved. However, 446 there are some small differences. 448 In datagram mode, the profile_id and connection_id fields allow a 449 server to reject almost all packets from a sender who does not know 450 the template (e.g. a DDoS attacker), with minimal CPU cost. 451 Pseudorandom cTLS requires the server to apply a decryption operation 452 to every incoming datagram before establishing whether it might be 453 valid. This operation is O(1) and uses only symmetric cryptography, 454 so the impact is expected to be bearable in most deployments. 456 cTLS templates are presumed to be published by the server operator. 457 In order to defend against ciphertext confusion attacks 458 (Section 3.3), the client MUST refuse to connect unless the server 459 provides a cTLS template with a sufficiently large "client-recipher" 460 value. 462 TODO: More precise security properties and security proof. The 463 goal we're after hasn't been widely considered in the literature 464 so far, at least as far as we can tell. The basic idea is that 465 the "real" protocol (Pseudorandom cTLS) should be 466 indistinguishable from some "target" protocol that the network is 467 known tolerate. The assumption is that middleboxes would not 468 attempt to parse packets whose contents are pseudorandom. (The 469 same idea underlies QUIC's wire encoding format [RFC9000].) A 470 starting point might be the formal notion of "Observational 471 Equivalence" (https://infsec.ethz.ch/content/dam/ethz/special- 472 interest/infk/inst-infsec/information-security-group- 473 dam/research/publications/pub2015/ASPObsEq.pdf). 475 7. Privacy Considerations 477 Pseudorandom cTLS is intended to improve privacy in scenarios where 478 the adversary can observe traffic to various servers but lacks access 479 to their cTLS templates, by preventing the adversary from determining 480 which profiles are in use by which clients and servers. If instead 481 the adversary does have access to some cTLS templates, and these 482 templates do not have distinctive profile_id values, Pseudorandom 483 cTLS can reduce privacy, by enabling strong confirmation that a 484 connection is using a specific profile. 486 When Pseudorandom cTLS is enabled, the adversary can still observe 487 the length and timing of messages, so templates that differ in these 488 can still be distinguished. Implementations MAY use TLS padding to 489 reduce the observable patterns. 491 The adversary could also send random data to the server (a "probing 492 attack") in order to learn the fraction of messages of each length 493 that produce valid ClientHellos. This "probability fingerprint" 494 could allow discrimination between profiles. Server operators that 495 wish to defend against probing attacks SHOULD choose a sufficiently 496 long profile_id that invalid ClientHellos are always rejected without 497 eliciting a response. A 15-byte profile_id provides 128-bit 498 security. 500 8. IANA Considerations 502 8.1. TSPRP Registry 504 This specification anticipates the existence of an IANA registry of 505 Tweakable Strong Pseudorandom Permutations (TSPRPs). Until such a 506 registry exists, the value "exp-hctr2" is reserved to indicate the 507 HCTR2 TSPRP [HCTR2]. 509 8.2. cTLS Template Key registry 511 This document requests that IANA add the following value to the "cTLS 512 Template Keys" registry: 514 +==============+===========+=================+ 515 | Key | JSON Type | Reference | 516 +==============+===========+=================+ 517 | pseudorandom | object | (This document) | 518 +--------------+-----------+-----------------+ 520 Table 1 522 8.3. TLS ContentType Registry 524 IANA is requested to add the following codepoint to the TLS Content 525 Types Registry 527 This document requests that a code point be allocated from the "TLS 528 ContentType" registry. The row to be added in the registry has the 529 following form: 531 +=======+====================+=========+===========+ 532 | Value | Description | DTLS-OK | Reference | 533 +=======+====================+=========+===========+ 534 | TBD | ctls_handshake_end | Y | RFCXXXX | 535 +-------+--------------------+---------+-----------+ 537 Table 2 539 9. References 541 9.1. Normative References 543 [cTLS] Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS 544 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 545 ctls-05, 7 March 2022, 546 . 549 [DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The 550 Datagram Transport Layer Security (DTLS) Protocol Version 551 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 552 dtls13-43, 30 April 2021, 553 . 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, 558 DOI 10.17487/RFC2119, March 1997, 559 . 561 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 562 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 563 May 2017, . 565 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 566 Multiplexed and Secure Transport", RFC 9000, 567 DOI 10.17487/RFC9000, May 2021, 568 . 570 9.2. Informative References 572 [HCTR2] "Length-preserving encryption with HCTR2", n.d., 573 . 575 [SLIPSTREAM] 576 "NAT Slipstreaming v2.0", n.d., 577 . 579 Acknowledgments 581 TODO 583 Authors' Addresses 585 Benjamin Schwartz 586 Google LLC 587 Email: bemasc@google.com 589 Christopher Patton 590 Cloudflare, Inc. 591 Email: cpatton@cloudflare.com