--- 1/draft-ietf-httpbis-encryption-encoding-05.txt 2016-12-22 19:13:08.109913385 -0800 +++ 2/draft-ietf-httpbis-encryption-encoding-06.txt 2016-12-22 19:13:08.141914134 -0800 @@ -1,18 +1,18 @@ HTTP Working Group M. Thomson Internet-Draft Mozilla -Intended status: Standards Track December 21, 2016 -Expires: June 24, 2017 +Intended status: Standards Track December 22, 2016 +Expires: June 25, 2017 Encrypted Content-Encoding for HTTP - draft-ietf-httpbis-encryption-encoding-05 + draft-ietf-httpbis-encryption-encoding-06 Abstract This memo introduces a content coding for HTTP that allows message payloads to be encrypted. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 24, 2017. + This Internet-Draft will expire on June 25, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -61,28 +61,28 @@ 2. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . . . 3 2.1. Encryption Content Coding Header . . . . . . . . . . . . 5 2.2. Content Encryption Key Derivation . . . . . . . . . . . . 6 2.3. Nonce Derivation . . . . . . . . . . . . . . . . . . . . 6 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Encryption of a Response . . . . . . . . . . . . . . . . 7 3.2. Encryption with Multiple Records . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4.1. Key and Nonce Reuse . . . . . . . . . . . . . . . . . . . 9 4.2. Data Encryption Limits . . . . . . . . . . . . . . . . . 9 - 4.3. Content Integrity . . . . . . . . . . . . . . . . . . . . 9 + 4.3. Content Integrity . . . . . . . . . . . . . . . . . . . . 10 4.4. Leaking Information in Headers . . . . . . . . . . . . . 10 - 4.5. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 10 + 4.5. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 11 4.6. Sizing and Timing Attacks . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5.1. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . 11 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. JWE Mapping . . . . . . . . . . . . . . . . . . . . 13 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction It is sometimes desirable to encrypt the contents of a HTTP message (request or response) so that when the payload is stored (e.g., with a HTTP PUT), only someone with the appropriate key can read it. @@ -145,51 +145,50 @@ The "aes128gcm" content coding uses a fixed record size. The final encoding consists of a header (see Section 2.1), zero or more fixed size encrypted records, and a partial record. The partial record MUST be shorter than the fixed record size. The record size determines the length of each portion of plaintext that is enciphered, with the exception of the final record, which is necessarily smaller. The record size ("rs") is included in the content coding header (see Section 2.1). - +-----------+ content is rs octets minus padding - | data | of between 2 and 65537 octets; + +-----------+ content of rs octets minus padding + | data | less padding (2-65537) and tag (16); +-----------+ the last record is smaller | v - +-----+-----------+ add padding to get rs octets; + +-----+-----------+ add padding to get rs-16 octets; | pad | data | the last record contains - +-----+-----------+ up to rs minus 1 octets + +-----+-----------+ up to rs minus 17 octets | v +--------------------+ encrypt with AEAD_AES_128_GCM; - | ciphertext | final size is rs plus 16 octets + | ciphertext | final size is rs; +--------------------+ the last record is smaller AEAD_AES_128_GCM produces ciphertext 16 octets longer than its input - plaintext. Therefore, the length of each enciphered record other - than the last is equal to the value of the "rs" parameter plus 16 - octets. If the final record ends on a record boundary, the encoder - MUST append a record that contains contains only padding and is - smaller than the full record size. A receiver MUST fail to decrypt - if the final record ciphertext is less than 18 octets in size or - equal to the record size plus 16 (that is, the size of a full - encrypted record). Valid records always contain at least two octets - of padding and a 16 octet authentication tag. + plaintext. Therefore, the unencrypted content of each record is + shorter than the record size by 16 octets. If the final record ends + on a record boundary, the encoder MUST append a record that contains + contains only padding and is smaller than the full record size. A + receiver MUST fail to decrypt if the final record ciphertext is less + than 18 octets in size or equal to the record size. Valid records + always contain at least a padding length of 2 octets and a 16 octet + authentication tag. - Each record contains a 2 octet padding length field and between 0 and - 65535 octets of padding, inserted into a record before the enciphered - content. The padding length is a two octet unsigned integer in - network byte order; padding is that number of zero-valued octets. A - receiver MUST fail to decrypt if any padding octet is non-zero, or a - record has more padding than the record size can accommodate. + Each record contains a 2 octet padding length and between 0 and 65535 + octets of padding, inserted into a record before the content. The + padding length is a two octet unsigned integer in network byte order; + padding is that number of zero-valued octets. A receiver MUST fail + to decrypt if any padding octet is non-zero, or a record has more + padding than the record size can accommodate. The nonce for each record is a 96-bit value constructed from the record sequence number and the input keying material. Nonce derivation is covered in Section 2.3. The additional data passed to each invocation of AEAD_AES_128_GCM is a zero-length octet sequence. A consequence of this record structure is that range requests [RFC7233] and random access to encrypted payload bodies are possible @@ -226,26 +225,28 @@ "aes128gcm" content coding header. The same "salt" parameter value MUST NOT be reused for two different payload bodies that have the same input keying material; generating a random salt for every application of the content coding ensures that content encryption key reuse is highly unlikely. rs: The "rs" or record size parameter contains an unsigned 32-bit integer in network byte order that describes the record size in octets. Note that it is therefore impossible to exceed the 2^36-31 limit on plaintext input to AEAD_AES_128_GCM. Values - smaller than 3 are invalid. + smaller than 19 are invalid. keyid: The "keyid" parameter can be used to identify the keying material that is used. Recipients that receive a message are expected to know how to retrieve keys; the "keyid" parameter might - be input to that process. + be input to that process. A "keyid" parameter SHOULD be a UTF-8 + [RFC3629] encoded string, particularly where the identifier might + need to appear in a textual form. 2.2. Content Encryption Key Derivation In order to allow the reuse of keying material for multiple different HTTP messages, a content encryption key is derived for each message. The content encryption key is derived from the "salt" parameter using the HMAC-based key derivation function (HKDF) described in [RFC5869] using the SHA-256 hash algorithm [FIPS180-4]. The value of the "salt" parameter is the salt input to HKDF function. @@ -340,32 +341,32 @@ salt (from header) = sJvlboCWzB5jr8hI_q9cOQ PRK = MLAQxt_DHjM15cdlyU1oUnjq7TFlzToGTkdRmvvxVBw CEK = v31u7VGV3soO3wNaMaIdhg NONCE = XOaygzko98zjUFTJ plaintext = AABJIGFtIHRoZSB3YWxydXM 3.2. Encryption with Multiple Records This example shows the same message with input keying material of "BO3ZVPxUlnLORbVGMpbT1Q". In this example, the plaintext is split - into records of 10 octets each (that is, the "rs" field in the header - is 10). The first record includes a single octet of padding. This + into records of 26 octets each (that is, the "rs" field in the header + is 26). The first record includes a single octet of padding. This means that there are 7 octets of message in the first record, and 8 in the second. This causes the end of the content to align with a record boundary, forcing the creation of a third record that contains only two octets of the padding length. HTTP/1.1 200 OK Content-Length: 93 Content-Encoding: aes128gcm - uNCkWiNYzKTnBN9ji3-qWAAAAAoCYTGHOqYFz-0in3dpb-VE2GfBngkaPy6bZus_ + uNCkWiNYzKTnBN9ji3-qWAAAABoCYTGHOqYFz-0in3dpb-VE2GfBngkaPy6bZus_ qLF79s6zQyTSsA0iLOKyd3JqVIwprNzVatRCWZGUx_qsFbJBCQu62RqQuR2d 4. Security Considerations This mechanism assumes the presence of a key management framework that is used to manage the distribution of keys between valid senders and receivers. Defining key management is part of composing this mechanism into a larger application, protocol, or framework. Implementation of cryptography - and key management in particular - @@ -397,26 +398,27 @@ There are limits to the data that AEAD_AES_128_GCM can encipher. The maximum value for the record size is limited by the size of the "rs" field in the header (see Section 2.1), which ensures that the 2^36-31 limit for a single application of AEAD_AES_128_GCM is not reached [RFC5116]. In order to preserve a 2^-40 probability of indistinguishability under chosen plaintext attack (IND-CPA), the total amount of plaintext that can be enciphered MUST be less than 2^44.5 blocks of 16 octets [AEBounds]. - If rs is a multiple of 16 octets, this means 398 terabytes can be - encrypted safely, including padding and overhead. However, if the - record size is not a multiple of 16 octets, the total amount of data - that can be safely encrypted is reduced proportionally. The worst - case is a record size of 3 octets, for which at most 74 terabytes of - plaintext can be encrypted, of which at least two-thirds is padding. + If the record size is a multiple of 16 octets, this means 398 + terabytes can be encrypted safely, including padding and overhead. + However, if the record size is not a multiple of 16 octets, the total + amount of data that can be safely encrypted is reduced because + partial AES blocks are encrypted. The worst case is a record size of + 19 octets, for which at most 74 terabytes of plaintext can be + encrypted, of which at least two-thirds is padding. 4.3. Content Integrity This mechanism only provides content origin authentication. The authentication tag only ensures that an entity with access to the content encryption key produced the encrypted data. Any entity with the content encryption key can therefore produce content that will be accepted as valid. This includes all recipients of the same HTTP message. @@ -510,20 +512,24 @@ Department of Commerce, National., "NIST FIPS 180-4, Secure Hash Standard", March 2012, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November + 2003, . + [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer