idnits 2.17.1 draft-nir-tls-keyshare-02.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 (March 26, 2012) is 4404 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) ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4366 (ref. 'TLS-EXT') (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. 'HTTPS') (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Standards Track March 26, 2012 5 Expires: September 27, 2012 7 A Method for Sharing Record Protocol Keys with a Middlebox in TLS 8 draft-nir-tls-keyshare-02 10 Abstract 12 This document contains a straw man proposal for a method for sharing 13 symmetric session keys between a TLS client and a middlebox, so that 14 the middlebox can decrypt the TLS-protected traffic. 16 This method is an alternative to the middlebox becoming a proxy. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 27, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 54 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. The tls_keyshare Extension . . . . . . . . . . . . . . . . 6 56 2.2. The KeyShareInfo Record . . . . . . . . . . . . . . . . . 6 57 2.2.1. The KeyShareInfo Discovery Subtype . . . . . . . . . . 6 58 2.2.2. The KeyShareInfo Rejection Subtype . . . . . . . . . . 6 59 2.2.3. The KeyShareInfo Keys Subtype . . . . . . . . . . . . 6 60 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1. Client Processing . . . . . . . . . . . . . . . . . . . . 7 62 3.2. Server Processing . . . . . . . . . . . . . . . . . . . . 7 63 3.3. Middlebox Processing . . . . . . . . . . . . . . . . . . . 8 64 4. Middlebox Discovery . . . . . . . . . . . . . . . . . . . . . 9 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 TLS ([TLS]) is used in a wide variety of protocols. The most common 75 use is for protecting HTTP, as described in [HTTPS]. Middleboxes 76 such as firewalls scan protocols for attacks. For HTTP common 77 attacks to scan for are cross-site scripting and transfer of files 78 containing malware. 80 TLS provides authentication and privacy against eavesdropping, but it 81 hides the traffic not only from mallicious intercepters. It also 82 hides the traffic from the middlebox, and prevents it from doing its 83 job. Our goal is to allow the middlebox to inspect the traffic, 84 without allowing others to do the same. 86 The requirements can be summed up in the following points: 87 o The middlebox should be able to decrypt all TLS traffic, and 88 optionally (the client's option) also modify it. 89 o The protocol must not make it easier for other entities to decrypt 90 the traffic. 91 o The client should be able to opt out of TLS decryption, but opting 92 out may mean that the connection is blocked. 93 o The server should be able to opt out of TLS decryption, but opting 94 out may mean that the connection is blocked. 96 Two proposals have been offered to achieve these goals. One is 97 having the middlebox be a proxy, acting as server to the client, and 98 as a client to the server. This option is implemented in several 99 commercial products. [proxy_server_ext] describes an extension to TLS 100 for improving that mechanism, and also contains a good description in 101 the introduction. 103 This document describes an alternative mechanism, where the client 104 sends the keys to the middlebox in the TLS record stream. This 105 requires more changes to clients and servers, but has the advantage 106 that it does not break many of TLS guarantees. 108 1.1. Conventions Used in This Document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 2. Protocol Overview 116 A supporting client will send a new extension in the ClientHello 117 message. This new extension is called tls_keyshare. A server that 118 supports this extension will send the extension in the ServerHello if 119 it has received that extension in the ClientHello. Note that sending 120 this extension only acknowledges understanding the protocol, not 121 agreement to decryption. The extension contains a sequence of SHA- 122 256 hashes of middlebox certificates. The client sends the hashes of 123 the certificates of middleboxes that it knows are on-path to the 124 server. See Section 4 for a discussion of middlebox discovery. The 125 server sends a subset of the same hashes, only those for which it 126 agrees to decryption. 128 This document defines a new record type called KeyshareInfo. This is 129 a new content type rather than a new handshake message so that it 130 doesn't figure in hash calculation of the hash message. A middlebox 131 inserts a KeyShareInfo record into the server-to-client stream 132 immediately after receiving the ClientHello message, if its hash was 133 not present in the client's tls_keyshare extension. It contains two 134 pieces of information: 135 o A certificate of the middlebox. The public key in the certificate 136 MUST be of the RSA type. The certificate should contain enough 137 information for the client to recognize the middlebox. 138 o A signature using the private key associated with the certificate 139 over the concatenation of the ClientHello and ServerHello 140 messages. 142 The middlebox inserts a KeyShareInfo record with a certificate into 143 the client-to-server stream without an alert, immediately following a 144 ServerHello message that does not contain the middlebox hash. The 145 server will reply with either a fatal UNAUTHORIZED_MIDDLEBOX alert, 146 or a fatal RETRY_MIDDLEBOX alert, depending on policy. 148 In cases where the client and server negotiate either a ciphersuite 149 that the middlebox does not support, or an extension that it doesn't 150 support, the middlebox inserts a different kind of KeyShareInfo 151 record into the stream, that identifies the unsupported ciphersuite 152 or extension. Both kinds of KeyShareInfo records are followed by a 153 fatal alert. The client is expected to add the hashes and remove the 154 unsupported ciphersuites and extensions, before attempting a new TLS 155 connection. 157 The client inserts a third type of KeyShareInfo record into the 158 client-to-server stream immediately following the ChangeCipherSpec 159 record (before the Finished handshake record). This KeyShareInfo 160 record is constructed differently, and contains an RSA encrypted 161 record of the write keys for both client and server. The client may 162 send several records if there is more than one middlebox. 164 The diagram below outlines discovery. 166 Client Middlebox Server 167 ------ --------- ------ 168 ClientHello(tls_keyshare=0) 169 --------> 170 KeyShareInfo(cert,sig) 171 KeyShareInfo(reject cipher:0x0044) 172 alert(MIDDLEBOX_PRESENT) 173 <-------- 174 ClientHello(tls_keyshare=cert_hash) 175 --------> 176 ServerHello(cert_hash) 177 (Certificate) 178 (ServerKeyExchange) 179 ServerHelloDone 180 <-------- 181 (Certificate) 182 ClientKeyExchange 183 (CertificateVerify) 184 ChangeCipherSpec 185 KeyShareInfo(keys) 186 Finished --------> 187 ChangeCipherSpec 188 Finished 189 <-------- 191 The diagram below outlines the protocol in a case where the server 192 refuses decryption. 194 Client Middlebox Server 195 ------ --------- ------ 197 ClientHello(tls_keyshare=cert_hash) 198 --------> 199 ServerHello(keyshare=0) 200 (Certificate) 201 (ServerKeyExchange) 202 ServerHelloDone 203 <-------- 204 KeyShareInfo(cert,sig) 205 --------> 206 alert(UNAUTHORIZED_MIDDLEBOX) 207 <-------- 209 2.1. The tls_keyshare Extension 211 The tls_keyshare extension is a ClientHello and ServerHello extension 212 as defined in section 2.3 of [TLS-EXT]. The extension_type field is 213 TBA by IANA. The format is to be added. 215 2.2. The KeyShareInfo Record 217 The format of the KeyShareInfo record is to be added. The content 218 type is TBA by IANA. 220 2.2.1. The KeyShareInfo Discovery Subtype 222 The KeyShareInfo Discovery record gives client or server information 223 about the middlebox. Format is TBA. 225 2.2.2. The KeyShareInfo Rejection Subtype 227 The KeyShareInfo Rejection record gives client a list of unsupported 228 ciphersuites and extensions. Format is TBA. 230 2.2.3. The KeyShareInfo Keys Subtype 232 The KeyShareInfo Keys record is send by the client to the middlebox 233 and includes the session keys. Format is TBA. 235 3. Processing 237 3.1. Client Processing 239 If the client policy prohibits decryption, the client SHOULD send the 240 tls_keyshare extension without hashes. Note that the middlebox might 241 still try to proxy the connection, but that is in conflict with this 242 specification, and is outside the scope of this document. 244 If there are some middleboxes that are by policy acceptable to the 245 client, their certificates are known in advance, and the client 246 believes that they are on-path to the server, then the client MUST 247 send the SHA-256 hashes of their certificates in the tls_keyshare 248 extension. 250 If a KeyShareInfo Discovery record is received with an unknown 251 certificate, it MAY be ignored, or the user MAY be prompted to 252 authorize the decryption, and optionally change the configuration to 253 allow future decryption by this certificate. There will certainly be 254 controversy about this, but the configuration must happen an some 255 point. 257 If policy dictates that the particular middlebox referenced in the 258 KeyShareInfo record is not allowed to decrypt, then such a record 259 MUST be ignored. In that case the connection fails. If the 260 middlebox is acceptable, then the client retries the connection, this 261 time adding the SHA-256 hash of the certificate to the tls_keyshare 262 extension. This is the discovery mechanism. 264 For all the middleboxes that are not ignored, the client MUST send a 265 KeyShareInfo record with the symmetric keys immediately following the 266 ChangeCipherSpec record before any protected record is sent. 268 If a KeyShareInfo Rejection record is received, the client SHOULD 269 retry the handshake, this time without the flagged ciphersuites and 270 extensions. If it is not acceptable to run the connection without 271 these ciphersuites or extensions, the client should log the event or 272 inform the user. 274 If the server sends a RETRY_MIDDLEBOX alert, the client should retry 275 the handshake. If it sends an UNAUTHORIZED_MIDDLEBOX alert, then the 276 client should log the event or alert the user. 278 3.2. Server Processing 280 The server SHOULD send the tls_keyshare extension even if policy 281 dictates that the decryption is prohibited. If policy allows all 282 middleboxex to decrypt, it makes sense to simply copy the client's 283 tls_keyshare extension. 285 If some of the middlebox hashes included in the client's tls_keyshare 286 extension are recognized as those of acceptable middleboxes, then 287 only those are copied to the server's tls_keyshare extension. When 288 the middlebox sends a KeyShareInfo Discovery record, the server may 289 decide whether that is acceptable or not, and accordingly send the 290 RETRY_MIDDLEBOX or UNAUTHORIZED_MIDDLEBOX alerts. In any case, every 291 time the server does not copy all hashes from the client's 292 tls_keyshare, the connection is probably going to end in an alert. 294 3.3. Middlebox Processing 296 The middlebox MUST send a KeyShareInfo Discovery record to the client 297 if the client has indicated support for this extension, and has not 298 included the middlebox hash in the extension. The discovery record 299 is followed by a MIDDLEBOX_PRESENT alert, breaking the connection. 300 Similarly, if the hash is missing from the server's tls_keyshare 301 extension, then the middlebox injects a KeyShareInfo Discovery record 302 into the client-to-server stream. The server will usually then send 303 an Alert record. 305 If the ServerHello specifies a ciphersuite that the middlebox does 306 not support, or if it includes a TLS extension that might prevent the 307 middlebox from processing, then the middlebox MAY send a KeyShareInfo 308 Reject record with all unacceptable ciphersuites and extension 309 numbers, followed by a MIDDLEBOX_PRESENT alert. 311 4. Middlebox Discovery 313 Discovering that the middlebox is present has already been described 314 in Section 3.1. The client that is not aware of the presence of the 315 middlebox receives a KeyShareInfo Discovery record followed by a 316 MIDDLEBOX_PRESENT alert message. 318 Discovering that a middlebox in no longer on the path is trickier, 319 because the superfluous KeyShareInfo Keys records do not lead to any 320 observable effects for the client. We suggest that the client keep a 321 list of discovered middleboxes, and periodically clear entries from 322 the list, requiring a repeated discovery. System events such as a 323 change to host IP address, a reboot or the computer entering sleep 324 mode MAY be used as triggers for clearing the list. 326 5. Security Considerations 328 To be added 330 6. IANA Considerations 332 To be added. 334 7. References 336 7.1. Normative References 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 342 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 344 [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 345 and T. Wright, "Transport Layer Security (TLS) 346 Extensions", RFC 4366, April 2006. 348 7.2. Informative References 350 [HTTPS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 352 [proxy_server_ext] 353 McGrew, D. and P. Gladstone, "TLS Proxy Server Extension", 354 draft-mcgrew-tls-proxy-server-00 (work in progress), 355 July 2011. 357 Author's Address 359 Yoav Nir 360 Check Point Software Technologies Ltd. 361 5 Hasolelim st. 362 Tel Aviv 67897 363 Israel 365 Email: ynir@checkpoint.com