--- 1/draft-ietf-httpbis-encryption-encoding-07.txt 2017-03-02 20:13:08.086615068 -0800 +++ 2/draft-ietf-httpbis-encryption-encoding-08.txt 2017-03-02 20:13:08.118615844 -0800 @@ -1,18 +1,18 @@ HTTP Working Group M. Thomson Internet-Draft Mozilla -Intended status: Standards Track February 13, 2017 -Expires: August 17, 2017 +Intended status: Standards Track March 2, 2017 +Expires: September 3, 2017 Encrypted Content-Encoding for HTTP - draft-ietf-httpbis-encryption-encoding-07 + draft-ietf-httpbis-encryption-encoding-08 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 August 17, 2017. + This Internet-Draft will expire on September 3, 2017. Copyright Notice Copyright (c) 2017 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,32 +61,32 @@ 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. Message Truncation . . . . . . . . . . . . . . . . . . . 9 4.2. Key and Nonce Reuse . . . . . . . . . . . . . . . . . . . 9 - 4.3. Data Encryption Limits . . . . . . . . . . . . . . . . . 9 + 4.3. Data Encryption Limits . . . . . . . . . . . . . . . . . 10 4.4. Content Integrity . . . . . . . . . . . . . . . . . . . . 10 4.5. Leaking Information in Header Fields . . . . . . . . . . 10 4.6. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 11 4.7. Sizing and Timing Attacks . . . . . . . . . . . . . . . . 11 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 5.1. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . 11 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 5.1. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. JWE Mapping . . . . . . . . . . . . . . . . . . . . 14 - Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 + Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 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. For example, it might be necessary to store a file on a server without exposing its contents to that server. Furthermore, that same @@ -151,42 +151,44 @@ The record size determines the length of each portion of plaintext that is enciphered. The record size ("rs") is included in the content coding header (see Section 2.1). +-----------+ content | data | any length up to rs-17 octets +-----------+ | v +-----------+-----+ add a delimiter octet (0x01 or 0x02) - | data | pad | the 0x00-valued octets to rs-16 + | data | pad | then 0x00-valued octets to rs-16 +-----------+-----+ (or less on the last record) | v +--------------------+ encrypt with AEAD_AES_128_GCM; | ciphertext | final size is rs; +--------------------+ the last record can be smaller AEAD_AES_128_GCM produces ciphertext 16 octets longer than its input plaintext. Therefore, the unencrypted content of each record is shorter than the record size by 16 octets. Valid records always contain at least a padding delimiter octet and a 16 octet authentication tag. Each record contains a single padding delimiter octet followed by any number of zero octets. The last record uses a padding delimiter octet set to the value 2, all other records have a padding delimiter - octet value of 1. A decrypter MUST fail if the unencrypted content - of a record is all zero-valued. A decrypter MUST fail if the last - record contains a padding delimiter with a value other than 2; a - decrypter MUST fail if any record other than the last contains a - padding delimiter with a value other than 1. + octet value of 1. + + On decryption, the padding delimiter is the last non-zero valued + octet of the record. A decrypter MUST fail if the record contains no + non-zero octet. A decrypter MUST fail if the last record contains a + padding delimiter with a value other than 2 or if any record other + than the last contains a padding delimiter with a value other than 1. 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 @@ -518,24 +523,25 @@ o Description: AES-GCM encryption with a 128-bit content encryption key o Reference: this specification 6. References 6.1. Normative References [FIPS180-4] - Department of Commerce, National., "NIST FIPS 180-4, - Secure Hash Standard", March 2012, - . + National Institute of Standards and Technology, U.S. + Department of Commerce, "NIST FIPS 180-4, Secure Hash + Standard", DOI 10.6028/NIST.FIPS.180-4, August 2015, + . [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, .