idnits 2.17.1 draft-schwartz-tls-lb-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2019) is 1763 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: 2 errors (**), 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 June 28, 2019 5 Expires: December 30, 2019 7 TLS Metadata for Load Balancers 8 draft-schwartz-tls-lb-00 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 December 30, 2019. 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. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Defined ProxyExtensions . . . . . . . . . . . . . . . . . . . 5 58 6. Use with TLS over TCP . . . . . . . . . . . . . . . . . . . . 5 59 7. Use with QUIC . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 6 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 10.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 66 Appendix B. Open Questions . . . . . . . . . . . . . . . . . . . 8 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Conventions and Definitions 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 73 "OPTIONAL" in this document are to be interpreted as described in 74 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 75 capitals, as shown here. 77 Data encodings are expressed in the TLS 1.3 presentation language, as 78 defined in Section 3 of [TLS13]. 80 2. Background 82 A load balancer is a server or bank of servers that acts as an 83 intermediary between the client and a range of backend servers. As 84 the name suggests, a load balancer's primary function is to ensure 85 that client traffic is spread evenly across the available backend 86 servers. However load balancers also serve many other functions, 87 such as identifying connections intended for different backends and 88 forwarding them appropriately, or dropping connections that are 89 deemed malicious. 91 A load balancer operates at a specific point in the protocol stack, 92 forwarding e.g. IP packets, TCP streams, TLS contents, HTTP 93 requests, etc. Most relevant to this proposal are TCP and TLS load 94 balancers. TCP load balancers terminate the TCP connection with the 95 client and establish a new TCP connection to the selected backend, 96 bidirectionally copying the TCP contents between these two 97 connections. TLS load balancers additionally terminate the TLS 98 connection, forwarding the plaintext to the backend server (typically 99 inside a new TLS connection). TLS load balancers must therefore hold 100 the private keys for the domains they serve. 102 When a TCP load balancer forwards a TLS stream, the load balancer has 103 no way to incorporate additional information into the stream. 104 Insertion of any additional data would cause the connection to fail. 105 However, the load-balancer and backend can share additional 106 information if they agree to speak a new protocol. The most popular 107 protocol used for this purpose is currently the PROXY protocol 108 [PROXY], developed by HAPROXY. This protocol prepends a plaintext 109 collection of metadata (e.g. client IP address) onto the TCP socket. 110 The backend can parse this metadata, then pass the remainder of the 111 stream to its TLS library. 113 The PROXY protocol is widely used, but it offers no confidentiality 114 or integrity protection, and therefore might not be suitable when the 115 load balancer and backend communicate over the public internet. 117 3. Goals 119 o Enable TCP load balancers to forward metadata to the backend. 121 o Reduce the need for TLS-terminating load balancers. 123 o Ensure confidentiality and integrity for all forwarded metadata. 125 o Enable split ESNI architectures. 127 o Prove to the backend that the load balancer intended to associate 128 this metadata with this connection. 130 o Achieve good CPU and memory efficiency. 132 o Don't impose additional latency. 134 o Support backends that receive a mixture of direct and load- 135 balanced TLS. 137 o Support use in QUIC. 139 o Enable simple and safe implementation. 141 4. Encoding 143 A ProxyExtension is identical in form to a standard TLS Extension 144 (Section 4.2 of [TLS13]), with a new identifier space for the 145 extension types. 147 struct { 148 ProxyExtensionType extension_type; 149 opaque extension_data<0..2^16-1>; 150 } ProxyExtension; 152 The ProxyData contains a set of ProxyExtensions. 154 struct { 155 ProxyExtension proxy_data<0..2^16-1>; 156 } ProxyData; 158 The EncryptedProxyData structure contains metadata associated with 159 the original ClientHello (Section 4.1.2 of [TLS13]), encrypted with a 160 pre-shared key that is configured out of band. 162 struct { 163 opaque psk_identity<1..2^16-1>; 164 opaque nonce<8..2^16-1> 165 opaque encrypted_proxy_data<1..2^16-1>; 166 } EncryptedProxyData; 168 o psk_identity: The identity of a PSK previously agreed upon by the 169 load balancer and the backend. Including the PSK identity allows 170 for updating the PSK without disruption. 172 o nonce: Non-repeating initializer for the AEAD. This prevents an 173 attacker from observing whether the same ClientHello is marked 174 with different metadata over time. 176 o encrypted_proxy_data: AEAD-Encrypt(key, nonce, 177 additional_data=ClientHello, plaintext=ProxyData). The key and 178 AEAD function are agreed out of band and associated with 179 psk_identity. 181 When the load balancer receives a ClientHello, it serializes any 182 relevant metadata into a ProxyData, then encrypts it with the 183 ClientHello as additional data, to produce EncryptedProxyData. 185 5. Defined ProxyExtensions 187 Like a standard TLS Extension, a ProxyExtension is identified by a 188 2-byte type number. There are initially three type numbers 189 allocated: 191 enum { 192 padding(0), 193 network_address(1), 194 esni_inner(2), 195 (65535) 196 } ProxyExtensionType; 198 The "padding" extension functions as described in [RFC7685]. It is 199 used here to avoid leaking information about the other extensions. 201 The "network_address" extension functions as described in 202 [I-D.kinnear-tls-client-net-address]. It conveys the client IP 203 address observed by the load balancer. 205 The "esni_inner" extension can only be used if the ClientHello 206 contains the encrypted_server_name extension [ESNI]. The 207 extension_data is the ClientESNIInner (Section 5.1.1 of [ESNI]), 208 which contains the true SNI and nonce. This is useful when the load 209 balancer knows the ESNI private key and the backend does not, i.e. 210 split mode ESNI. 212 Load balancers SHOULD only include extensions that are specified for 213 use in ProxyData, and backends MUST ignore any extensions that they 214 do not recognize. 216 6. Use with TLS over TCP 218 When forwarding a TLS stream over TCP, the load balancer SHOULD send 219 a ProxyHeader at the beginning of the stream: 221 struct { 222 uint8 opaque_type = 0; 223 ProtocolVersion version = 0; 224 uint16 length = length(ProxyHeader.contents); 225 EncryptedProxyData contents; 226 } ProxyHeader; 228 The opaque_type field ensures that this header is distinguishable 229 from an ordinary TLS connection, whose first byte is always 22 230 (ContentType = handshake in Section 5.1 of [TLS13]). This structure 231 matches the layout of TLSPlaintext with a ContentType of "invalid", 232 potentially simplifying parsing. 234 Following the ProxyHeader, the load balancer MUST send the full 235 contents of the TCP stream, exactly as received from the client. The 236 backend will observe the ProxyHeader, immediately followed by a 237 TLSPlaintext frame containing the ClientHello. The backend will 238 decrypt the ProxyHeader using the ClientHello as associated data, and 239 process the ClientHello and the remainder of the stream as standard 240 TLS. 242 When receiving a ProxyHeader with an unrecognized version, the 243 backend SHOULD ignore this ProxyHeader and proceed as if the 244 following byte were the first byte received. 246 7. Use with QUIC 248 A QUIC load balancer provides this service by extracting the 249 ClientHello from any Initial packet that contains a complete 250 ClientHello [I-D.ietf-quic-tls]. The load balancer then computes 251 EncryptedProxyData and constructs a new packet consisting of the 252 4-byte value TBD (a reserved QUIC version number), the 253 EncryptedProxyData, and the entire Initial. 255 The backend, upon receipt of a packet with QUIC version TBD, reverses 256 this transformation to recover the original Initial packet and 257 extract the proxy data for this connection. 259 8. Configuration 261 The method of configuring of the PSK on the load balancer and backend 262 is not specified here. However, the PSK MAY be represented as a 263 ProxyKey: 265 struct { 266 ProtocolVersion version = 0; 267 opaque psk_identity<1..2^16-1>; 268 CipherSuite cipher_suite; 269 opaque key<16..2^16-1> 270 } ProxyKey; 272 9. IANA Considerations 274 Need to create a new ProxyExtensionType registry. 276 Need to allocate TBD as a reserved QUIC version code. 278 10. References 280 10.1. Normative References 282 [ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 283 "Encrypted Server Name Indication for TLS 1.3", draft- 284 ietf-tls-esni-03 (work in progress), March 2019. 286 [I-D.ietf-quic-tls] 287 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 288 draft-ietf-quic-tls-20 (work in progress), April 2019. 290 [I-D.kinnear-tls-client-net-address] 291 Kinnear, E., Pauly, T., and C. Wood, "TLS Client Network 292 Address Extension", draft-kinnear-tls-client-net- 293 address-00 (work in progress), March 2019. 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, 297 DOI 10.17487/RFC2119, March 1997, 298 . 300 [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello 301 Padding Extension", RFC 7685, DOI 10.17487/RFC7685, 302 October 2015, . 304 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 305 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 306 May 2017, . 308 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 309 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 310 . 312 10.2. Informative References 314 [PROXY] Tarreau, W., "The PROXY protocol", March 2017, 315 . 318 Appendix A. Acknowledgements 320 This is an elaboration of an idea proposed by Eric Rescorla during 321 the development of ESNI. Thanks to David Schinazi and David Benjamin 322 for suggesting important improvements. 324 Appendix B. Open Questions 326 Should the ProxyExtensionType registry have a reserved range for 327 private extensions? 329 Author's Address 331 Benjamin M. Schwartz 332 Google LLC 334 Email: bemasc@google.com