idnits 2.17.1 draft-nottingham-http-encryption-encoding-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 : ---------------------------------------------------------------------------- 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 5, 2015) is 3339 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft 4 Intended status: Informational M. Thomson 5 Expires: September 6, 2015 Mozilla 6 March 5, 2015 8 Encrypted Content-Encoding for HTTP 9 draft-nottingham-http-encryption-encoding-00 11 Abstract 13 This memo introduces a content-coding for HTTP that allows message 14 payloads to be encrypted. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 6, 2015. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 52 2. The "aesgcm-128" HTTP content-coding . . . . . . . . . . . . 3 53 3. The "Encryption" HTTP header field . . . . . . . . . . . . . 5 54 3.1. Encryption Header Field Parameters . . . . . . . . . . . 5 55 3.2. Content Encryption Key Derivation . . . . . . . . . . . . 6 56 4. Encryption-Key Header Field . . . . . . . . . . . . . . . . . 6 57 4.1. Explicit Key . . . . . . . . . . . . . . . . . . . . . . 7 58 4.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . . . 7 59 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 5.1. Successful GET Response . . . . . . . . . . . . . . . . . 8 61 5.2. Encryption and Compression . . . . . . . . . . . . . . . 8 62 5.3. Encryption with More Than One Key . . . . . . . . . . . . 8 63 5.4. Encryption with Explicit Key . . . . . . . . . . . . . . 9 64 5.5. Diffie-Hellman Encryption . . . . . . . . . . . . . . . . 9 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 6.1. The "aesgcm-128" HTTP content-coding . . . . . . . . . . 10 67 6.2. Encryption Header Fields . . . . . . . . . . . . . . . . 10 68 6.3. The HTTP Encryption Parameter Registry . . . . . . . . . 10 69 6.3.1. keyid . . . . . . . . . . . . . . . . . . . . . . . . 11 70 6.3.2. salt . . . . . . . . . . . . . . . . . . . . . . . . 11 71 6.3.3. rs . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 6.4. The HTTP Encryption-Key Parameter Registry . . . . . . . 11 73 6.4.1. keyid . . . . . . . . . . . . . . . . . . . . . . . . 12 74 6.4.2. key . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6.4.3. dh . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 7.1. Key and Nonce Reuse . . . . . . . . . . . . . . . . . . . 13 78 7.2. Content Integrity . . . . . . . . . . . . . . . . . . . . 13 79 7.3. Leaking Information in Headers . . . . . . . . . . . . . 13 80 7.4. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 14 81 7.5. Sizing and Timing Attacks . . . . . . . . . . . . . . . . 14 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 84 8.2. Informative References . . . . . . . . . . . . . . . . . 15 85 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 It is sometimes desirable to encrypt the contents of a HTTP message 91 (request or response) in a persistent manner, so that when the 92 payload is stored (e.g., with a HTTP PUT), only someone with the 93 appropriate key can read it. 95 For example, it might be necessary to store a file on a server 96 without exposing its contents to that server. Furthermore, that same 97 file could be replicated to other servers (to make it more resistant 98 to server or network failure), downloaded by clients (to make it 99 available offline), etc. without exposing its contents. 101 These uses are not met by the use of TLS [RFC5246], since it only 102 encrypts the channel between the client and server. 104 Message-based encryption formats - such as those that are described 105 by [RFC4880], [RFC5652], [I-D.ietf-jose-json-web-encryption], and 106 [XMLENC] - are not suited to stream processing, which is necessary 107 for HTTP messages. While virtually any of these alternatives could 108 be profiled and adapted to suit, the overhead and complexity that 109 would introduce is sub-optimal. 111 This document specifies a content-coding [RFC7231]) for HTTP to serve 112 these and other use cases. 114 This mechanism is likely only a small part of a larger design that 115 uses content encryption. In particular, this document does not 116 describe key management practices. How clients and servers acquire 117 and identify keys will depend on the use case. 119 1.1. Notational Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 2. The "aesgcm-128" HTTP content-coding 127 The "aesgcm-128" HTTP content-coding indicates that a payload has 128 been encrypted using Advanced Encryption Standard (AES) in Galois/ 129 Counter Mode (GCM) as identified as AEAD_AES_128_GCM in [RFC5116], 130 Section 5.1. The AEAD_AES_128_GCM algorithm uses a 128 bit content 131 encryption key. 133 When this content-coding is in use, the Encryption header field 134 Section 3 describes how encryption has been applied. The Encryption- 135 Key header field Section 4 can be included to describe how the the 136 content encryption key is derived or retrieved. 138 The "aesgcm-128" content-coding uses a single fixed set of encryption 139 primitives. Cipher suite agility is achieved by defining a new 140 content-coding scheme. This ensures that only the HTTP Accept- 141 Encoding header field is necessary to negotiate the use of 142 encryption. 144 The "aesgcm-128" content-coding uses a fixed record size. The 145 resulting encoding is a series of fixed-size records, though the 146 final record can contain any amount of data. 148 +------+ 149 | data | input of between rs-256 150 +------+ and rs-1 octets 151 | 152 v 153 +-----+-----------+ 154 | pad | data | add padding to form plaintext 155 +-----+-----------+ 156 | 157 v 158 +--------------------+ 159 | ciphertext | encrypt with AEAD_AES_128_GCM 160 +--------------------+ expands by 16 octets 162 The record size determines the length of each portion of plaintext 163 that is enciphered. The record size defaults to 4096 octets, but can 164 be changed using the "rs" parameter on the Encryption header field. 166 AEAD_AES_128_GCM expands ciphertext to be 16 octets longer than its 167 input plaintext. Therefore, the length of each enciphered record is 168 equal to the value of the "rs" parameter plus 16 octets. It is a 169 fatal decryption error to have a remainder of 16 octets or less in 170 size (though AEAD_AES_128_GCM permits input plaintext to be zero 171 length, records always contain at least one padding octet). 173 Each record contains between 0 and 255 octets of padding, inserted 174 into a record before the enciphered content. The length of the 175 padding is stored in the first octet of the payload. All padding 176 octets MUST be set to zero. It is a fatal decryption error to have a 177 record with more padding than the record size. 179 The nonce used for each record is a 96-bit value containing the index 180 of the current record in network byte order. Records are indexed 181 starting at zero. 183 The additional data passed to the AEAD algorithm is a zero-length 184 octet sequence. 186 Issue: Double check that having no AAD is safe. 188 3. The "Encryption" HTTP header field 190 The "Encryption" HTTP header field describes the encrypted content 191 encoding(s) that have been applied to a message payload, and 192 therefore how those content encoding(s) can be removed. 194 Encryption-val = #encryption_params 195 encryption_params = [ param *( ";" param ) ] 197 If the payload is encrypted more than once (as reflected by having 198 multiple content-codings that imply encryption), each application of 199 the content encoding is reflected in the Encryption header field, in 200 the order in which they were applied. 202 The Encryption header MAY be omitted if the sender does not intend 203 for the immediate recipient to be able to decrypt the message. 204 Alternatively, the Encryption header field MAY be omitted if the 205 sender intends for the recipient to acquire the header field by other 206 means. 208 Servers processing PUT requests MUST persist the value of the 209 Encryption header field, unless they remove the content-coding by 210 decrypting the payload. 212 3.1. Encryption Header Field Parameters 214 The following parameters are used in determining the key that is used 215 for encryption: 217 keyid: The "keyid" parameter contains a string that identifies the 218 keying material that is used. The "keyid" parameter SHOULD be 219 included, unless key identification is guaranteed by other means. 220 The "keyid" parameter MUST be used if keying material is included 221 in an Encryption-Key header field. 223 salt: The "salt" parameter contains a base64 URL-encoded octets that 224 is used as salt in deriving a unique content encryption key (see 225 Section 3.2). The "salt" parameter MUST be present, and MUST be 226 exactly 16 octets long. The "salt" parameter MUST NOT be reused 227 for two different messages that have the same content encryption 228 key; generating a random nonce for each message ensures that reuse 229 is highly unlikely. 231 rs: The "rs" parameter contains a positive decimal integer that 232 describes the record size in octets. This value MUST be greater 233 than 1. If the "rs" parameter is absent, the record size defaults 234 to 4096 octets. 236 3.2. Content Encryption Key Derivation 238 In order to allow the reuse of keying material for multiple different 239 messages, a content encryption key is derived for each message. This 240 key is derived from the decoded value of the "s" parameter using the 241 HMAC-based key derivation function (HKDF) described in [RFC5869] 242 using the SHA-256 hash algorithm [FIPS180-2]. 244 The decoded value of the "salt" parameter is the salt input to HKDF 245 function. The keying material identified by the "keyid" parameter is 246 the input keying material (IKM) to HKDF. Input keying material can 247 either be prearranged, or can be described using the Encryption-Key 248 header field Section 4. The first step of HKDF is therefore: 250 PRK = HMAC-SHA-256(salt, IKM) 252 AEAD_AES_128_GCM requires 16 octets (128 bits) of key, so the length 253 (L) parameter of HKDF is 16. The info parameter is set to the ASCII- 254 encoded string "Content-Encoding: aesgcm128". The second step of 255 HKDF can therefore be simplified to the first 16 octets of a single 256 HMAC: 258 OKM = HMAC-SHA-256(PRK, "Content-Encoding: aesgcm128" || 0x01) 260 4. Encryption-Key Header Field 262 An Encryption-Key header field can be used to describe the input 263 keying material used in the Encryption header field. 265 Encryption-Key-val = #encryption_key_params 266 encryption_key_params = [ param *( ";" param ) ] 268 keyid: The "keyid" parameter corresponds to the "keyid" parameter in 269 the Encryption header field. 271 key: The "key" parameter contains the URL-safe base64 [RFC4648] 272 octets of the input keying material. 274 dh: The "dh" parameter contains an ephemeral Diffie-Hellman share. 275 This form of the header field can be used to encrypt content for a 276 specific recipient. 278 The input keying material used by the content-encoding key derivation 279 (see Section 3.2) can be determined based on the information in the 280 Encryption-Key header field. The method for key derivation depends 281 on the parameters that are present in the header field. 283 Note that different methods for determining input keying materal will 284 produce different amounts of data. The HKDF process ensures that the 285 final content encryption key is the necessary size. 287 Alternative methods for determining input keying material MAY be 288 defined by specifications that use this content-encoding. 290 4.1. Explicit Key 292 The "key" parameter is decoded and used directly if present. The 293 "key" parameter MUST decode to exactly 16 octets in order to be used 294 as input keying material for "aesgcm128" content encoding. 296 Other key determination parameters can be ignored if the "key" 297 parameter is present. 299 4.2. Diffie-Hellman 301 The "dh" parameter is included to describe a Diffie-Hellman share, 302 either modp (or finite field) Diffie-Hellman [DH] or elliptic curve 303 Diffie-Hellman (ECDH) [RFC4492]. 305 This share is combined with other information at the recipient to 306 determine the HKDF input keying material. In order for the exchange 307 to be successful, the following information MUST be established out 308 of band: 310 o Which Diffie-Hellman form is used. 312 o The modp group or elliptic curve that will be used. 314 o The format of the ephemeral public share that is included in the 315 "dh" parameter. For instance, using ECDH both parties need to 316 agree whether this is an uncompressed or compressed point. 318 In addition to identifying which content-encoding this input keying 319 material is used for, the "keyid" parameter is used to identify this 320 additional information at the receiver. 322 The intended recipient recovers their private key and are then able 323 to generate a shared secret using the appropriate Diffie-Hellman 324 process. 326 Specifications that rely on an Diffie-Hellman exchange for 327 determining input keying material MUST either specify the parameters 328 for Diffie-Hellman (group parameters, or curves and point format) 329 that are used, or describe how those parameters are negotiated 330 between sender and receiver. 332 5. Examples 334 5.1. Successful GET Response 336 HTTP/1.1 200 OK 337 Content-Type: application/octet-stream 338 Content-Encoding: aesgcm-128 339 Connection: close 340 Encryption: keyid="http://example.org/bob/keys/123"; 341 salt="XZwpw6o37R-6qoZjw6KwAw" 343 [encrypted payload] 345 Here, a successful HTTP GET response has been encrypted using a key 346 that is identified by a URI. 348 Note that the media type has been changed to "application/octet- 349 stream" to avoid exposing information about the content. 351 5.2. Encryption and Compression 353 HTTP/1.1 200 OK 354 Content-Type: text/html 355 Content-Encoding: aesgcm-128, gzip 356 Transfer-Encoding: chunked 357 Encryption: keyid="mailto:me@example.com"; 358 salt="m2hJ_NttRtFyUiMRPwfpHA" 360 [encrypted payload] 362 5.3. Encryption with More Than One Key 364 PUT /thing HTTP/1.1 365 Host: storage.example.com 366 Content-Type: application/http 367 Content-Encoding: aesgcm-128, aesgcm-128 368 Content-Length: 1234 369 Encryption: keyid="mailto:me@example.com"; 370 salt="NfzOeuV5USPRA-n_9s1Lag", 371 keyid="http://example.org/bob/keys/123"; 372 salt="bDMSGoc2uobK_IhavSHsHA"; rs=1200 374 [encrypted payload] 376 Here, a PUT request has been encrypted with two keys; both will be 377 necessary to read the content. The outer layer of encryption uses a 378 1200 octet record size. 380 5.4. Encryption with Explicit Key 382 HTTP/1.1 200 OK 383 Content-Length: 31 384 Content-Encoding: aesgcm-128 385 Encryption: keyid="a1"; salt="owIfQR647esVfrzCW_i9GQ" 386 Encryption-Key: keyid="a1"; key="JcqK-OLkJZlJ3sJJWstJCA" 388 LwTC-fwdKh8de0smD2jfzHodb1EYbuuTNpcYXLW257Q 390 This example shows the string "I am the walrus" encrypted using an 391 explicit key. The content body contains a single record only and is 392 shown here encoded in URL-safe base64 for presentation reasons only. 394 5.5. Diffie-Hellman Encryption 396 HTTP/1.1 200 OK 397 Content-Length: 31 398 Content-Encoding: aesgcm-128 399 Encryption: keyid="dhkey"; salt="XYFSCgMVjc45IMfLOcMfiw" 400 Encryption-Key: keyid="dhkey"; 401 dh="BELKqvZ7n3p5C9_ipP_6X9DBNAGuJujSN7YWbtcGZMMH 402 3urZM-zlii3mGGCMjlqR-yWwiPlMdKRdOL8gQSdHw8E" 404 P6ikHE_wyKnYHXxLswvuFBO3JJOZpM1Bg3KikQEmczU 406 This example shows the same string, "I am the walrus", encrypted 407 using ECDH over the P-256 curve [FIPS186]. The content body is shown 408 here encoded in URL-safe base64 for presentation reasons only. 410 The receiver (in this case, the HTTP client) uses the key identified 411 by the string "dhkey" and the sender (the server) uses a key pair for 412 which the public share is included in the "dh" parameter above. The 413 keys shown below use uncompressed points [X.692] encoded using URL- 414 safe base64. Line wrapping is added for presentation purposes only. 416 Receiver: 417 private key: QjGwenE3vCg8Eajo-PukGgUkYq8Vu-SQn04Cc9DR-YA 418 public key: BBM3pYS4nXG6bQYnZbGDY7l6CVrQTZ-1u00h7XV6A_TD 419 v7mXvv5k29uoLid8SdDycw341PJTW4hNCe2FNysN52U 420 Sender: 421 private key: wlC-qzKBWO6jYq32nlD0ZZVsI5jGVBC1gN7zkXjaPks 422 public key: 424 6. IANA Considerations 426 6.1. The "aesgcm-128" HTTP content-coding 428 This memo registers the "encrypted" HTTP content-coding in the HTTP 429 Content Codings Registry, as detailed in Section 2. 431 o Name: aesgcm-128 433 o Description: AES-GCM encryption with a 128-bit key 435 o Reference [this specification] 437 6.2. Encryption Header Fields 439 This memo registers the "Encryption" HTTP header field in the 440 Permanent Message Header Registry, as detailed in Section 3. 442 o Field name: Encryption 444 o Protocol: HTTP 446 o Status: Standard 448 o Reference: [this specification] 450 o Notes: 452 This memo registers the "Encryption-Key" HTTP header field in the 453 Permanent Message Header Registry, as detailed in Section 4. 455 o Field name: Encryption-Key 457 o Protocol: HTTP 459 o Status: Standard 461 o Reference: [this specification] 463 o Notes: 465 6.3. The HTTP Encryption Parameter Registry 467 This memo establishes a registry for parameters used by the 468 "Encryption" header field under the "Hypertext Transfer Protocol 469 (HTTP) Parameters" grouping. The "Hypertext Transfer Protocol (HTTP) 470 Encryption Parameters" operates under an "Specification Required" 471 policy [RFC5226]. 473 Entries in this registry are expected to include the following 474 information: 476 o Parameter Name: The name of the parameter. 478 o Purpose: A brief description of the purpose of the parameter. 480 o Reference: A reference to a specification that defines the 481 semantics of the parameter. 483 The initial contents of this registry are: 485 6.3.1. keyid 487 o Parameter Name: keyid 489 o Purpose: Identify the key that is in use. 491 o Reference: [this document] 493 6.3.2. salt 495 o Parameter Name: salt 497 o Purpose: Provide a source of entropy for derivation of the content 498 encryption key. This value is mandatory. 500 o Reference: [this document] 502 6.3.3. rs 504 o Parameter Name: rs 506 o Purpose: The size of the encrypted records. 508 o Reference: [this document] 510 6.4. The HTTP Encryption-Key Parameter Registry 512 This memo establishes a registry for parameters used by the 513 "Encryption-Key" header field under the "Hypertext Transfer Protocol 514 (HTTP) Parameters" grouping. The "Hypertext Transfer Protocol (HTTP) 515 Encryption Parameters" operates under an "Specification Required" 516 policy [RFC5226]. 518 Entries in this registry are expected to include the following 519 information: 521 o Parameter Name: The name of the parameter. 523 o Purpose: A brief description of the purpose of the parameter. 525 o Reference: A reference to a specification that defines the 526 semantics of the parameter. 528 The initial contents of this registry are: 530 6.4.1. keyid 532 o Parameter Name: keyid 534 o Purpose: Identify the key that is in use. 536 o Reference: [this document] 538 6.4.2. key 540 o Parameter Name: key 542 o Purpose: Provide an explicit key. 544 o Reference: [this document] 546 6.4.3. dh 548 o Parameter Name: dh 550 o Purpose: Carry a modp or elliptic curve Diffie-Hellman share used 551 to derive a key. 553 o Reference: [this document] 555 7. Security Considerations 557 This mechanism assumes the presence of a key management framework 558 that is used to manage the distribution of keys between valid senders 559 and receivers. Defining key management is part of composing this 560 mechanism into a larger application, protocol, or framework. 562 Implementation of cryptography - and key management in particular - 563 can be difficult. For instance, implementations need to account for 564 the potential for exposing keying material on side channels, such as 565 might be exposed by the time it takes to perform a given operation. 566 The requirements for a good implementation of cryptographic 567 algorithms can change over time. 569 7.1. Key and Nonce Reuse 571 Encrypting different plaintext with the same content encryption key 572 and nonce in AES-GCM is not safe [RFC5116]. The scheme defined here 573 relies on the uniqueness of the "nonce" parameter to ensure that the 574 content encryption key is different for every message. 576 If a key and nonce are reused, this could expose the content 577 encryption key and it makes message modification trivial. If the 578 same key is used for multiple messages, then the nonce parameter MUST 579 be unique for each. An implementation SHOULD generate a random nonce 580 parameter for every message, though using a counter could achieve the 581 desired result. 583 7.2. Content Integrity 585 This mechanism only provides content origin authentication. The 586 authentication tag only ensures that those with access to the content 587 encryption key produce a message that will be accepted as valid. 589 Any entity with the content encryption key can therefore produce 590 content that will be accepted as valid. This includes all recipients 591 of the same message. 593 Furthermore, any entity that is able to modify both the Encryption 594 header field and the message payload can replace messages. Without 595 the content encryption key however, modifications to or replacement 596 of parts of a message are not possible. 598 7.3. Leaking Information in Headers 600 Because "encrypted" only operates upon the message payload, any 601 information exposed in headers is visible to anyone who can read the 602 message. 604 For example, the Content-Type header can leak information about the 605 message payload. 607 There are a number of strategies available to mitigate this threat, 608 depending upon the application's threat model and the users' 609 tolerance for leaked information: 611 1. Determine that it is not an issue. For example, if it is 612 expected that all content stored will be "application/json", or 613 another very common media type, exposing the Content-Type header 614 could be an acceptable risk. 616 2. If it is considered sensitive information and it is possible to 617 determine it through other means (e.g., out of band, using hints 618 in other representations, etc.), omit the relevant headers, and/ 619 or normalize them. In the case of Content-Type, this could be 620 accomplished by always sending Content-Type: application/octet- 621 stream (the most generic media type). 623 3. If it is considered sensitive information and it is not possible 624 to convey it elsewhere, encapsulate the HTTP message using the 625 application/http media type [RFC7230], encrypting that as the 626 payload of the "outer" message. 628 7.4. Poisoning Storage 630 This mechanism only offers encryption of content; it does not perform 631 authentication or authorization, which still needs to be performed 632 (e.g., by HTTP authentication [RFC7235]). 634 This is especially relevant when a HTTP PUT request is accepted by a 635 server; if the request is unauthenticated, it becomes possible for a 636 third party to deny service and/or poison the store. 638 7.5. Sizing and Timing Attacks 640 Applications using this mechanism need to be aware that the size of 641 encrypted messages, as well as their timing, HTTP methods, URIs and 642 so on, may leak sensitive information. 644 This risk can be mitigated through the use of the padding that this 645 mechanism provides. Alternatively, splitting up content into 646 segments and storing the separately might reduce exposure. HTTP/2 647 [I-D.ietf-httpbis-http2] combined with TLS [RFC5246] might be used to 648 hide the size of individual messages. 650 8. References 652 8.1. Normative References 654 [DH] Diffie, W. and M. Hellman, "New Directions in 655 Cryptography", IEEE Transactions on Information Theory, 656 V.IT-22 n.6 , June 1977. 658 [FIPS180-2] 659 Department of Commerce, National., "NIST FIPS 180-2, 660 Secure Hash Standard", August 2002. 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, March 1997. 665 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 666 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 667 for Transport Layer Security (TLS)", RFC 4492, May 2006. 669 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 670 Encodings", RFC 4648, October 2006. 672 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 673 Encryption", RFC 5116, January 2008. 675 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 676 Key Derivation Function (HKDF)", RFC 5869, May 2010. 678 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 679 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 680 2014. 682 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 683 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 685 8.2. Informative References 687 [FIPS186] National Institute of Standards and Technology (NIST), 688 "Digital Signature Standard (DSS)", NIST PUB 186-4 , July 689 2013. 691 [I-D.ietf-httpbis-http2] 692 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 693 Protocol version 2", draft-ietf-httpbis-http2-17 (work in 694 progress), February 2015. 696 [I-D.ietf-jose-json-web-encryption] 697 Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 698 draft-ietf-jose-json-web-encryption-40 (work in progress), 699 January 2015. 701 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 702 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 704 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 705 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 706 May 2008. 708 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 709 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 711 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 712 RFC 5652, September 2009. 714 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 715 (HTTP/1.1): Authentication", RFC 7235, June 2014. 717 [X.692] ANSI, "Public Key Cryptography For The Financial Services 718 Industry: The Elliptic Curve Digital Signature Algorithm 719 (ECDSA)", ANSI X9.62, 1998. , n.d.. 721 [XMLENC] Eastlake, D., Reagle, J., Imamura, T., Dillaway, B., and 722 E. Simon, "XML Encryption Syntax and Processing", W3C REC 723 , December 2002, . 725 Appendix A. Acknowledgements 727 The following people provided valuable feedback and suggestions: 728 Richard Barnes, Stephen Farrell, Eric Rescorla, and Jim Schaad. 730 Authors' Addresses 732 Mark Nottingham 734 Email: mnot@mnot.net 735 URI: http://www.mnot.net/ 737 Martin Thomson 738 Mozilla 740 Email: martin.thomson@gmail.com