idnits 2.17.1 draft-hoffman-httpbis-minimal-unauth-enc-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 (December 03, 2013) is 3796 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 (-17) exists of draft-ietf-httpbis-http2-08 ** Downref: Normative reference to an Informational RFC: RFC 5114 ** Downref: Normative reference to an Informational RFC: RFC 5869 == Outdated reference: A later version (-03) exists of draft-nottingham-http2-encryption-01 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Intended status: Standards Track December 03, 2013 5 Expires: June 06, 2014 7 Minimal Unauthenticated Encryption (MUE) for HTTP/2 8 draft-hoffman-httpbis-minimal-unauth-enc-01 10 Abstract 12 HTTP/2 can be run under TLS as a transport if the origin for the 13 request is an https: URL. There is a desire to encrypt much more web 14 traffic than just the traffic that is already encrypted with TLS. 15 This document proposes a method to establish unauthenticated 16 encryption within normal HTTP/2 flows to prevent passive surveillance 17 using as few as zero additional round trips. The method described 18 here is definitely less robust than normal TLS and is thus not 19 offered as an alternative to TLS for https: URLs; it is only offered 20 as a fast way within HTTP/2 to cause unauthenticated encryption. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 06, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Cryptography Used in MUE . . . . . . . . . . . . . . . . 3 60 2.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Server Response . . . . . . . . . . . . . . . . . . . . . 4 62 2.3.1. Server Can Use Key Material from C1 and Agrees With 63 Proposed Algorithms . . . . . . . . . . . . . . . . . 4 64 2.3.2. Server Cannot Use Key Material from C1, But Agrees 65 With Proposed Algorithms . . . . . . . . . . . . . . 5 66 2.3.3. Explicit Rejection by the Server . . . . . . . . . . 6 67 2.4. Key Derivation . . . . . . . . . . . . . . . . . . . . . 6 68 2.4.1. Definiton of HKDF-SHA256-MUE . . . . . . . . . . . . 6 69 3. Message Format for the New Headers . . . . . . . . . . . . . 7 70 4. Encrypting HTTP/2 Content . . . . . . . . . . . . . . . . . . 7 71 5. Mandatory-to-Implement Crypto Algorithms . . . . . . . . . . 7 72 6. Comparison of MUE with Redirection to TLS . . . . . . . . . . 7 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 9.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 The httpbis WG is investigating how to encrypt HTTP/2 83 [I-D.ietf-httpbis-http2] traffic using opportunistic methods for 84 origins that use the http: URL. An earlier proposal 85 ([I-D.nottingham-http2-encryption]) uses HTTP/2 headers to signal 86 that the communication should switch to TLS [RFC5246]. This proposal 87 uses a different mechanism: it creates a pair of encryption keys in 88 HTTP/2 and uses that to encrypt the content while still running on 89 port 80. A very comparison of the two methods is given in Section 6. 91 The protocol in this document is called minimal unauthenticated 92 encryption (MUE). "Minimal" means that the protocol uses as few 93 round trips as possible, and "unauthenticated" means that neither 94 party is authenticated to the other. The lack of authentication 95 makes this protocol faster and less complicated, but at the expense 96 of making it suitable for preventing only passive surveillance, not 97 attacks where the attacker is on-path. 99 The protocol described here starts encryption within three messages 100 (1.5 round trips), and can start encryption successfully before the 101 first message is sent back from the server to the client. This 102 reduction of round trips before the beginning of encryption is 103 possible because the protocol limits the types of key agreement and 104 cryptographic negotiation that is possible. Other models have been 105 proposed that can come to agreement with sometimes using fewer than 106 two round trips, but at the expense of much more complicated error 107 handling and sometimes needing even more than two round trips. 108 Notably, QUIC [QUIC] appears to have achieved the most aggressive 109 reduction under optimum circumstances, but with a pretty complicated 110 model for connections between peers that don't know each other or 111 when a peer changes long-term keys for any reason. 113 1.1. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119, BCP 14 118 [RFC2119] and indicate requirement levels for compliant CBOR 119 implementations. 121 2. Protocol Overview 123 MUE is negotiated in HTTP/2 headers. MUE is only initiated by the 124 client. There are only three possible MUE messages: C1 (the first 125 client message), S1 (the first server message), and C2 (the second 126 client message, which is not needed if the server agreed to all the 127 client's offers in C1). The two parties agree to a shared 128 preliminary key using Diffie-Hellman key agreement, derive a pair of 129 shared encryption keys using an agreed-to key derivation function 130 (KDF), and start encrypting messages with an agreed-to encryption 131 algorithm. 133 2.1. Cryptography Used in MUE 135 MUE uses three cryptographic primitves: key agreement, KDF, 136 encryption. 138 The key agreement function used by MUE MUST be a form of anonymous 139 Diffie-Hellman. This assures that that forward secrecy is always 140 established as long as either the client or the server uses a newly- 141 generated value. 143 The KDF MUST be an HMAC-based KDF as described in [RFC5869]. 145 The encryption algorithm used by MUE MUST use authenticated 146 encryption with associated data (AEAD) as defined in [RFC5116]. 148 2.2. Client Initiation 150 C1 contains: 152 o the client's initial keying material 154 o the identifier for the type of key agreement used, including any 155 parameters that are needed 157 o a list of all the crypto algorithms (key agreement, KDF, 158 encryption) the client is willing to use 160 o the client nonce 162 If the client supports all the mandatory-to-implement algorithms (see 163 Section 5), it can use the key agreement from that list and have a 164 good guess that the server will be able to agree immediately. If the 165 client has had a key agreement with the server in the past, the 166 client might remember the server's algorithms and use those if they 167 do not match the mandatory-to-implement list. 169 2.3. Server Response 171 S1 contains one of three things: agreement with the proposals in C1 172 and a finishing of the exchange, preliminary keying material based on 173 one of the other key agreement algorithms and a list of the accepted 174 algorithms, or an explicit rejection of doing MUE at all. 176 2.3.1. Server Can Use Key Material from C1 and Agrees With Proposed 177 Algorithms 179 In the case of full agreement, S1 contains the following: 181 o an indicator of server success 183 o the server's keying material 184 o the list of just the agreed-to crypto algorithms (key agreement, 185 KDF, encryption) 187 o the server nonce 189 The two sides use the KDF to convert the preliminary key to a pair of 190 encryption keys. At that point, both the client and the server can 191 begin encrypting HTTP/2 traffic. There is thus no C2 message. 193 2.3.2. Server Cannot Use Key Material from C1, But Agrees With Proposed 194 Algorithms 196 If the server cannot use the client's keying material from C1 (most 197 likely because the server does not support the key agreement type), 198 but the client's list of crypto algorithms contains enough algorithms 199 for the server to want to try, the server starts the key agreement 200 over with a different key agreement algorithm. In this case, S1 201 contains: 203 o an indicator that the server is going to try to initiate the key 204 exchange 206 o the server's initial keying material 208 o the identifier for the type of key agreement used, including any 209 parameters that are needed 211 o the list of just the agreed-to crypto algorithms (key agreement, 212 KDF, encryption) 214 o the server nonce 216 After receiving this S1, the client has two choices: reject the 217 message (and send a C2 that would contain just an error indication), 218 or accept it. In the latter case, C2 contains: 220 o an indicator of client success 222 o the client's keying material 224 o the list of just the agreed-to crypto algorithms (key agreement, 225 KDF, encryption) 227 o the client nonce 229 The two sides use the KDF to convert the preliminary key to a pair of 230 encryption keys. At that point, both the client and the server can 231 begin encrypting HTTP/2 traffic. 233 2.3.3. Explicit Rejection by the Server 235 The server can explicitly reject the client's attempt to start MUE 236 for any reason it wants. For example, the server may not be able to 237 use any of the KDFs or encryption algorithms proposed by the client. 238 Another example is that the server might not want to encrypt this 239 particular traffic because it knows that the traffic is internal to a 240 security zone. In this case, S1 would contain just an error 241 indication, and there would be no C2 message. 243 2.4. Key Derivation 245 When the two parties have a preliminary key, it needs to be converted 246 into a pair of encryption keys that can be used for encryption by the 247 KDF. Each KDF is defined separately; one KDM is defined in 248 Section 2.4.1. 250 Using the terminology of RFC 5869: 252 o the IKM is the preliminary key 254 o L is 2 times the length of the encryption keys needed plus 8 256 o the OKM is split into three items in the following order: 258 * the client-to-server encryption key 260 * the server-to-client encryption key 262 * an 8-octet value that is used as a nonce for the AEAD 264 2.4.1. Definiton of HKDF-SHA256-MUE 266 This document defines one HKDF, "HKDF-SHA256-MUE". It follows the 267 pattern described in RFC 5869 and has the following fields defined: 269 o Hash: SHA-256 271 o Salt: C1 | S1 | C2 (if C2 doesn't exist, the salt is just C1 | S1 272 ) 274 o Info: the value 0x6d75652d687474702f32 276 3. Message Format for the New Headers 278 ...is a bikeshed that can be painted later. Seriously, it can be any 279 binary format such as CBOR [RFC7049], some new TLV construct, or any 280 of the many binary formats listed in Appendix E of the CBOR 281 specification. 283 4. Encrypting HTTP/2 Content 285 ...is not specified here yet. The topic of "I have a shared key and 286 agreed-to encryption algorithm, I want to encrypt some of this HTTP 287 content" has been widely discussed over the decade and many full and 288 partial protocols have been presented. This document does not yet 289 choose any of those, but it will clearly have to do so before it is 290 complete. The httpbis WG can decide, given the differences between 291 HTTP/1.1 and HTTP/2, what material (headers, messages, and so on) 292 could be encrypted once a key and an algorithm is agreed to. (It is 293 noted that there are two encryption keys, one for messages from the 294 client to the server, and the other for the messages from the server 295 to the client.) 297 5. Mandatory-to-Implement Crypto Algorithms 299 The following are the mandatory-to-implement algorithms. A client 300 using just these choices is likely to be able to achieve encryption 301 for the server's first message. (Note that the actual values can 302 change as this document is discussed, but the list should have at 303 least one value for each item.) 305 o Key agreement: ECDH with NIST curve P-256 [RFC5114] 307 o KDF: HKDF-SHA256-MUE as defined in Section 2.4.1 309 o Encryption: AES-256 in GCM mode [RFC5084] 311 6. Comparison of MUE with Redirection to TLS 313 One reason for doing encryption in the HTTP/2 stream instead of 314 switching ports is that the transport semantics are clearer because 315 HTTP/2 continues to run over TCP instead of in TLS. If a web browser 316 starts with an http: URL type in the address bar, but then switches 317 to TLS, should the GUI change at all? Would such a change be 318 confusing to the user? Even if there is no change, how would the 319 browser deal with a change in origins for any relative links in the 320 HTML that is served from the https: redirection? 322 Another reason for using MUE is that it takes far fewer round trips 323 than redirection to TLS. Browser vendors have been trying to reduce 324 the number of round trips before a user sees web content, and adding 325 many round trips in order to do opportunistic encryption may be 326 considered too expensive to them. MUE can achieve unauthenticated 327 encryption in the first server response; redirection to TLS takes the 328 three-way TCP handshake plus two TCP-level round trips. 330 Another reason that the httpbis WG might be interested in MUE is that 331 it plays well with HTTP proxies given that it is all done in HTTP. 333 The main reason for doing encryption by redirecting to TLS is that 334 the HTTP world already has TLS stacks and knows how to use them. 335 Although there might need to be some changes either to the TLS API or 336 even TLS itself to allow for unauthenticated TLS, this still might be 337 much less work than adding crypto to HTTP/2 itself. 339 Another reason for doing encryption by redirection is that there will 340 be complexity in specifying how HTTP/2 clients and servers will know 341 which headers and body content is encrypted. 343 7. IANA Considerations 345 There will be a registry with all the codepoint values for the crypto 346 algorithms. It will start small. 348 8. Security Considerations 350 MUE is only used for http: URLs, not at all for https: URLs. MUE and 351 TLS solve different security problems and should definitely not be 352 mistaken for each other. In all circumstances where TLS is used with 353 server authentication, TLS has stronger security properties than MUE. 354 Having said that, there is no security problem using MUE in the HTTP 355 that is being carried under TLS. 357 Because MUE uses no authentication, it is susceptible to man-in-the- 358 middle (MITM) attacks from active attackers. MUE's only security 359 goal is to prevent passive surveillance, not to give any assurance to 360 either party that there is no MITM. 362 Given the difference between MUE's security and TLS's security, and 363 given the fact that many users do not even understand what security 364 is given by TLS, implementers who add a green-lock GUI element for 365 this type of encryption are likely to confuse users. 367 9. References 369 9.1. Normative References 371 [I-D.ietf-httpbis-http2] 372 Belshe, M., Peon, R., Thomson, M., and A. Melnikov, 373 "Hypertext Transfer Protocol version 2.0", draft-ietf- 374 httpbis-http2-08 (work in progress), November 2013. 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 380 Encryption in the Cryptographic Message Syntax (CMS)", RFC 381 5084, November 2007. 383 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 384 Groups for Use with IETF Standards", RFC 5114, January 385 2008. 387 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 388 Key Derivation Function (HKDF)", RFC 5869, May 2010. 390 9.2. Informative References 392 [I-D.nottingham-http2-encryption] 393 Nottingham, M., "Opportunistic Encryption for HTTP URIs", 394 draft-nottingham-http2-encryption-01 (work in progress), 395 October 2013. 397 [QUIC] Langley, A. and W-T. Chang, "QUIC Crypto", June 2013, 398 . 401 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 402 Encryption", RFC 5116, January 2008. 404 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 405 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 407 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 408 Representation (CBOR)", RFC 7049, October 2013. 410 Author's Address 412 Paul Hoffman 413 VPN Consortium 415 Email: paul.hoffman@vpnc.org