idnits 2.17.1 draft-schwartz-tls-lb-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 02, 2019) is 1759 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-03 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-20 ** Downref: Normative reference to an Informational draft: draft-kinnear-tls-client-net-address (ref. 'I-D.kinnear-tls-client-net-address') Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls B. Schwartz 3 Internet-Draft Google LLC 4 Intended status: Standards Track July 02, 2019 5 Expires: January 3, 2020 7 TLS Metadata for Load Balancers 8 draft-schwartz-tls-lb-01 10 Abstract 12 A load balancer that does not terminate TLS may wish to provide some 13 information to the backend server, in addition to forwarding TLS 14 data. This draft proposes a protocol between load balancers and 15 backends that enables secure, efficient delivery of TLS with 16 additional information. The need for such a protocol has recently 17 become apparent in the context of split mode ESNI. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 3, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 54 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. Defined ProxyExtensions . . . . . . . . . . . . . . . . . . . 5 59 7. Use with TLS over TCP . . . . . . . . . . . . . . . . . . . . 6 60 8. Use with QUIC . . . . . . . . . . . . . . . . . . . . . . . . 6 61 9. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 8 62 10. Security considerations . . . . . . . . . . . . . . . . . . . 9 63 10.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . 9 64 10.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 9 65 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 68 12.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 70 Appendix B. Open Questions . . . . . . . . . . . . . . . . . . . 11 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Conventions and Definitions 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 77 "OPTIONAL" in this document are to be interpreted as described in 78 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 79 capitals, as shown here. 81 Data encodings are expressed in the TLS 1.3 presentation language, as 82 defined in Section 3 of [TLS13]. 84 2. Background 86 A load balancer is a server or bank of servers that acts as an 87 intermediary between the client and a range of backend servers. As 88 the name suggests, a load balancer's primary function is to ensure 89 that client traffic is spread evenly across the available backend 90 servers. However load balancers also serve many other functions, 91 such as identifying connections intended for different backends and 92 forwarding them appropriately, or dropping connections that are 93 deemed malicious. 95 A load balancer operates at a specific point in the protocol stack, 96 forwarding e.g. IP packets, TCP streams, TLS contents, HTTP 97 requests, etc. Most relevant to this proposal are TCP and TLS load 98 balancers. TCP load balancers terminate the TCP connection with the 99 client and establish a new TCP connection to the selected backend, 100 bidirectionally copying the TCP contents between these two 101 connections. TLS load balancers additionally terminate the TLS 102 connection, forwarding the plaintext to the backend server (typically 103 inside a new TLS connection). TLS load balancers must therefore hold 104 the private keys for the domains they serve. 106 When a TCP load balancer forwards a TLS stream, the load balancer has 107 no way to incorporate additional information into the stream. 108 Insertion of any additional data would cause the connection to fail. 109 However, the load-balancer and backend can share additional 110 information if they agree to speak a new protocol. The most popular 111 protocol used for this purpose is currently the PROXY protocol 112 [PROXY], developed by HAPROXY. This protocol prepends a plaintext 113 collection of metadata (e.g. client IP address) onto the TCP socket. 114 The backend can parse this metadata, then pass the remainder of the 115 stream to its TLS library. 117 The PROXY protocol is widely used, but it offers no confidentiality 118 or integrity protection, and therefore might not be suitable when the 119 load balancer and backend communicate over the public internet. 121 3. Goals 123 o Enable TCP load balancers to forward metadata to the backend. 125 o Reduce the need for TLS-terminating load balancers. 127 o Ensure confidentiality and integrity for all forwarded metadata. 129 o Enable split ESNI architectures. 131 o Prove to the backend that the load balancer intended to associate 132 this metadata with this connection. 134 o Achieve good CPU and memory efficiency. 136 o Don't impose additional latency. 138 o Support backends that receive a mixture of direct and load- 139 balanced TLS. 141 o Support use in QUIC. 143 o Enable simple and safe implementation. 145 4. Overview 147 The proposed protocol provides one-way communication from a load 148 balancer to a backend server. It works by prepending information to 149 the forwarded connection: 151 +-----------+ +-----------+ +-----------+ 152 | Backend A | | Backend B | | Backend C | 153 +-----------+ +-----------+ +-----------+ 154 \/ /\ 155 4. ServerHello, \/ /\ 2. EncryptedProxyData[SNI: "secret.b", 156 etc. \/ /\ client: 2, etc.] 157 \/ /\ 3. ClientHello (verbatim) 158 \/ /\ 159 +---------------+ 160 | Load balancer | 161 +---------------+ 162 \/ /\ 163 5. ServerHello, \/ /\ 1. ClientHello[ESNI: enc("secret.b")] 164 etc. (verbatim) \/ /\ 165 \/ /\ 166 +-----------+ +-----------+ +-----------+ 167 | Client 1 | | Client 2 | | Client 3 | 168 +-----------+ +-----------+ +-----------+ 170 Figure 1: Data flow diagram 172 5. Encoding 174 A ProxyExtension is identical in form to a standard TLS Extension 175 (Section 4.2 of [TLS13]), with a new identifier space for the 176 extension types. 178 struct { 179 ProxyExtensionType extension_type; 180 opaque extension_data<0..2^16-1>; 181 } ProxyExtension; 183 The ProxyData contains a set of ProxyExtensions. 185 struct { 186 ProxyExtension proxy_data<0..2^16-1>; 187 } ProxyData; 188 The EncryptedProxyData structure contains metadata associated with 189 the original ClientHello (Section 4.1.2 of [TLS13]), encrypted with a 190 pre-shared key that is configured out of band. 192 struct { 193 opaque psk_identity<1..2^16-1>; 194 opaque nonce<8..2^16-1> 195 opaque encrypted_proxy_data<1..2^16-1>; 196 } EncryptedProxyData; 198 o psk_identity: The identity of a PSK previously agreed upon by the 199 load balancer and the backend. Including the PSK identity allows 200 for updating the PSK without disruption. 202 o nonce: Non-repeating initializer for the AEAD. This prevents an 203 attacker from observing whether the same ClientHello is marked 204 with different metadata over time. 206 o encrypted_proxy_data: AEAD-Encrypt(key, nonce, 207 additional_data=ClientHello, plaintext=ProxyData). The key and 208 AEAD function are agreed out of band and associated with 209 psk_identity. 211 When the load balancer receives a ClientHello, it serializes any 212 relevant metadata into a ProxyData, then encrypts it with the 213 ClientHello as additional data, to produce EncryptedProxyData. 215 6. Defined ProxyExtensions 217 Like a standard TLS Extension, a ProxyExtension is identified by a 218 2-byte type number. There are initially three type numbers 219 allocated: 221 enum { 222 padding(0), 223 network_address(1), 224 esni_inner(2), 225 (65535) 226 } ProxyExtensionType; 228 The "padding" extension functions as described in [RFC7685]. It is 229 used here to avoid leaking information about the other extensions. 231 The "network_address" extension functions as described in 232 [I-D.kinnear-tls-client-net-address]. It conveys the client IP 233 address observed by the load balancer. 235 The "esni_inner" extension can only be used if the ClientHello 236 contains the encrypted_server_name extension [ESNI]. The 237 extension_data is the ClientESNIInner (Section 5.1.1 of [ESNI]), 238 which contains the true SNI and nonce. This is useful when the load 239 balancer knows the ESNI private key and the backend does not, i.e. 240 split mode ESNI. 242 Load balancers SHOULD only include extensions that are specified for 243 use in ProxyData, and backends MUST ignore any extensions that they 244 do not recognize. 246 7. Use with TLS over TCP 248 When forwarding a TLS stream over TCP, the load balancer SHOULD send 249 a ProxyHeader at the beginning of the stream: 251 struct { 252 uint8 opaque_type = 0; 253 ProtocolVersion version = 0; 254 uint16 length = length(ProxyHeader.contents); 255 EncryptedProxyData contents; 256 } ProxyHeader; 258 The opaque_type field ensures that this header is distinguishable 259 from an ordinary TLS connection, whose first byte is always 22 260 (ContentType = handshake in Section 5.1 of [TLS13]). This structure 261 matches the layout of TLSPlaintext with a ContentType of "invalid", 262 potentially simplifying parsing. 264 Following the ProxyHeader, the load balancer MUST send the full 265 contents of the TCP stream, exactly as received from the client. The 266 backend will observe the ProxyHeader, immediately followed by a 267 TLSPlaintext frame containing the ClientHello. The backend will 268 decrypt the ProxyHeader using the ClientHello as associated data, and 269 process the ClientHello and the remainder of the stream as standard 270 TLS. 272 When receiving a ProxyHeader with an unrecognized version, the 273 backend SHOULD ignore this ProxyHeader and proceed as if the 274 following byte were the first byte received. 276 8. Use with QUIC 278 A QUIC load balancer provides this service by extracting the 279 ClientHello from any client Initial packet [I-D.ietf-quic-tls]. A 280 multi-tenant load balancer needs to perform this extraction anyway in 281 order to determine where the connection should be forwarded, either 282 by SNI or ESNI. 284 Extracting a TLS ClientHello from a QUIC handshake is a version- 285 dependent action, so a load balancer cannot support unrecognized 286 versions of QUIC. If the load balancer receives a packet with an 287 unrecognized QUIC version, it MUST reply with a VersionNegotiation 288 packet indicating the supported versions (currently only version 1). 289 If the backend applies downgrade protection, it SHOULD account for 290 the impact of the load balancer. 292 In QUIC version 1, each handshake begins with an Initial packet sent 293 by the client. This packet uses the QUIC "long header" packet form, 294 starting with a "fixed bit" of 1 and a "frame type" of 0x0. 296 +-+-+-+-+-+-+-+-+ 297 |1|1| 0 |R R|P P| 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Version (32) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |DCIL(4)|SCIL(4)| 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Destination Connection ID (0/32..144) ... 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Source Connection ID (0/32..144) ... 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Token Length (i) ... 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Token (*) ... 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Length (i) ... 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Packet Number (8/16/24/32) ... 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Payload (*) ... 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 2: QUIC Initial Packet 320 A client Initial packet contains a complete ClientHello, in a CRYPTO 321 frame in the payload. The load balancer extracts this ClientHello in 322 order to compute EncryptedProxyData. 324 TODO: Confirm that HelloRetryRequest elicits an Initial containing a 325 complete ClientHello. The QUIC draft text is unclear. 327 To send EncryptedProxyData to the backend, the load balancer 328 constructs a new packet with a header copied from the Initial, but 329 with a frame type of 0x1 and a new version (0xTBD). Its payload 330 consists of the old Initial's version number (currently always 1) and 331 the EncryptedProxyData. 333 +-+-+-+-+-+-+-+-+ 334 |1|1| 1 |R R|P P| 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | New Version, 0xTBD (32) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 |DCIL(4)|SCIL(4)| 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Destination Connection ID (0/32..144) ... 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Source Connection ID (0/32..144) ... 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Token Length (i) ... 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Token (*) ... 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | New Length (i) ... 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Packet Number (8/16/24/32) ... 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Initial Version (32) ... 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | EncryptedProxyData ... 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Figure 3: EncryptedProxyData packet to the backend 359 The load balancer then forwards the client Initial unmodified, except 360 for replacing its Version number with 0xTBD. All other QUIC packets 361 are forwarded entirely unmodified. 363 The backend, upon receipt of a packet with QUIC version 0xTBD and 364 type "0" or "1", waits for a second packet with version 0xTBD, the 365 other type value, and matching connection IDs, token, and packet 366 number. When both packets have been received, the backend can 367 reconstruct the original Initial packet and decrypt the 368 EncryptedProxyData. 370 If the second packet is not received within a brief time period (e.g. 371 100 ms), the backend SHOULD discard the first packet. 373 9. Configuration 375 The method of configuring of the PSK on the load balancer and backend 376 is not specified here. However, the PSK MAY be represented as a 377 ProxyKey: 379 struct { 380 ProtocolVersion version = 0; 381 opaque psk_identity<1..2^16-1>; 382 CipherSuite cipher_suite; 383 opaque key<16..2^16-1> 384 } ProxyKey; 386 10. Security considerations 388 10.1. Integrity 390 This protocol is intended to provide the backend with a strong 391 guarantee of integrity for the metadata written by the load balancer. 392 For example, an active attacker cannot take metadata intended for one 393 stream and attach it to another, because each stream will have a 394 unique ClientHello, and the metadata is bound to the ClientHello by 395 AEAD. 397 One exception to this protection is in the case of an attacker who 398 deliberately reissues identical ClientHello messages. An attacker 399 who reuses a ClientHello can also reuse the metadata associated with 400 it, if they can first observe the EncryptedProxyData transferred 401 between the load balancer and the backend. This could be used by an 402 attacker to reissue data originally generated by a true client (e.g. 403 as part of a 0-RTT replay attack), or it could be used by a group of 404 adversaries who are willing to share a single set of client secrets 405 while initiating different sessions, in order to reuse metadata that 406 they find helpful. 408 As such, the backend SHOULD treat this metadata as advisory. 410 10.2. Confidentiality 412 This protocol is intended to maintain confidentiality of the metadata 413 transferred between the load balancer and backend, currently 414 consisting of the ESNI plaintext and the client IP address. An 415 observer between the client and the load balancer does not observe 416 this protocol at all, and an observer between the load balancer and 417 backend observes only ciphertext. 419 However, an adversary who can monitor both of these links can easily 420 observe that a connection from the client to the load balancer is 421 shortly followed by a connection from the load balancer to a backend, 422 with the same ClientHello. This reveals which backend server the 423 client intended to visit. In many cases, the choice of backend 424 server could be the sensitive information that ESNI is intended to 425 protect. 427 11. IANA Considerations 429 Need to create a new ProxyExtensionType registry. 431 Need to allocate TBD as a reserved QUIC version code. 433 12. References 435 12.1. Normative References 437 [ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 438 "Encrypted Server Name Indication for TLS 1.3", draft- 439 ietf-tls-esni-03 (work in progress), March 2019. 441 [I-D.ietf-quic-tls] 442 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 443 draft-ietf-quic-tls-20 (work in progress), April 2019. 445 [I-D.kinnear-tls-client-net-address] 446 Kinnear, E., Pauly, T., and C. Wood, "TLS Client Network 447 Address Extension", draft-kinnear-tls-client-net- 448 address-00 (work in progress), March 2019. 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, 452 DOI 10.17487/RFC2119, March 1997, 453 . 455 [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello 456 Padding Extension", RFC 7685, DOI 10.17487/RFC7685, 457 October 2015, . 459 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 460 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 461 May 2017, . 463 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 464 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 465 . 467 12.2. Informative References 469 [PROXY] Tarreau, W., "The PROXY protocol", March 2017, 470 . 473 Appendix A. Acknowledgements 475 This is an elaboration of an idea proposed by Eric Rescorla during 476 the development of ESNI. Thanks to David Schinazi and David Benjamin 477 for suggesting important improvements. 479 Appendix B. Open Questions 481 Should the ProxyExtensionType registry have a reserved range for 482 private extensions? 484 Author's Address 486 Benjamin M. Schwartz 487 Google LLC 489 Email: bemasc@google.com