draft-ietf-httpbis-encryption-encoding-01.txt   draft-ietf-httpbis-encryption-encoding-02.txt 
HTTP Working Group M. Thomson HTTP Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track March 20, 2016 Intended status: Standards Track June 29, 2016
Expires: September 21, 2016 Expires: December 31, 2016
Encrypted Content-Encoding for HTTP Encrypted Content-Encoding for HTTP
draft-ietf-httpbis-encryption-encoding-01 draft-ietf-httpbis-encryption-encoding-02
Abstract Abstract
This memo introduces a content-coding for HTTP that allows message This memo introduces a content-coding for HTTP that allows message
payloads to be encrypted. payloads to be encrypted.
Note to Readers Note to Readers
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 21, 2016. This Internet-Draft will expire on December 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. The "aesgcm" HTTP Content Encoding . . . . . . . . . . . . . 4 2. The "aesgcm" HTTP Content Encoding . . . . . . . . . . . . . 4
3. The Encryption HTTP Header Field . . . . . . . . . . . . . . 5 3. The Encryption HTTP Header Field . . . . . . . . . . . . . . 6
3.1. Encryption Header Field Parameters . . . . . . . . . . . 6 3.1. Encryption Header Field Parameters . . . . . . . . . . . 6
3.2. Content Encryption Key Derivation . . . . . . . . . . . . 7 3.2. Content Encryption Key Derivation . . . . . . . . . . . . 7
3.3. Nonce Derivation . . . . . . . . . . . . . . . . . . . . 7 3.3. Nonce Derivation . . . . . . . . . . . . . . . . . . . . 8
4. Crypto-Key Header Field . . . . . . . . . . . . . . . . . . . 8 4. Crypto-Key Header Field . . . . . . . . . . . . . . . . . . . 8
4.1. Explicit Key . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Explicit Key . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . . . 9 4.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . . . 9
4.3. Pre-shared Authentication Secrets . . . . . . . . . . . . 10 4.3. Pre-shared Authentication Secrets . . . . . . . . . . . . 11
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Successful GET Response . . . . . . . . . . . . . . . . . 11 5.1. Successful GET Response . . . . . . . . . . . . . . . . . 12
5.2. Encryption and Compression . . . . . . . . . . . . . . . 12 5.2. Encryption and Compression . . . . . . . . . . . . . . . 12
5.3. Encryption with More Than One Key . . . . . . . . . . . . 12 5.3. Encryption with More Than One Key . . . . . . . . . . . . 12
5.4. Encryption with Explicit Key . . . . . . . . . . . . . . 12 5.4. Encryption with Explicit Key . . . . . . . . . . . . . . 13
5.5. Encryption with Multiple Records . . . . . . . . . . . . 13 5.5. Encryption with Multiple Records . . . . . . . . . . . . 13
5.6. Diffie-Hellman Encryption . . . . . . . . . . . . . . . . 13 5.6. Diffie-Hellman Encryption . . . . . . . . . . . . . . . . 14
5.7. Diffie-Hellman with Authentication Secret . . . . . . . . 14 5.7. Diffie-Hellman with Authentication Secret . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. Key and Nonce Reuse . . . . . . . . . . . . . . . . . . . 15 6.1. Key and Nonce Reuse . . . . . . . . . . . . . . . . . . . 15
6.2. Content Integrity . . . . . . . . . . . . . . . . . . . . 15 6.2. Data Encryption Limits . . . . . . . . . . . . . . . . . 16
6.3. Leaking Information in Headers . . . . . . . . . . . . . 15 6.3. Content Integrity . . . . . . . . . . . . . . . . . . . . 16
6.4. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 16 6.4. Leaking Information in Headers . . . . . . . . . . . . . 16
6.5. Sizing and Timing Attacks . . . . . . . . . . . . . . . . 16 6.5. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.6. Sizing and Timing Attacks . . . . . . . . . . . . . . . . 17
7.1. The "aesgcm" HTTP Content Encoding . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.2. Encryption Header Fields . . . . . . . . . . . . . . . . 17 7.1. The "aesgcm" HTTP Content Encoding . . . . . . . . . . . 17
7.3. The HTTP Encryption Parameter Registry . . . . . . . . . 17 7.2. Encryption Header Fields . . . . . . . . . . . . . . . . 18
7.3.1. keyid . . . . . . . . . . . . . . . . . . . . . . . . 18 7.3. The HTTP Encryption Parameter Registry . . . . . . . . . 18
7.3.2. salt . . . . . . . . . . . . . . . . . . . . . . . . 18 7.3.1. keyid . . . . . . . . . . . . . . . . . . . . . . . . 19
7.3.3. rs . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.3.2. salt . . . . . . . . . . . . . . . . . . . . . . . . 19
7.4. The HTTP Crypto-Key Parameter Registry . . . . . . . . . 18 7.3.3. rs . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.4.1. keyid . . . . . . . . . . . . . . . . . . . . . . . . 19 7.4. The HTTP Crypto-Key Parameter Registry . . . . . . . . . 19
7.4.2. aesgcm . . . . . . . . . . . . . . . . . . . . . . . 19 7.4.1. keyid . . . . . . . . . . . . . . . . . . . . . . . . 20
7.4.3. dh . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.4.2. aesgcm . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.4.3. dh . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
Appendix A. JWE Mapping . . . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix B. Intermediate Values for Encryption . . . . . . . . . 22 Appendix A. JWE Mapping . . . . . . . . . . . . . . . . . . . . 22
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 23 Appendix B. Intermediate Values for Encryption . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
It is sometimes desirable to encrypt the contents of a HTTP message 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 (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. 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 For example, it might be necessary to store a file on a server
without exposing its contents to that server. Furthermore, that same without exposing its contents to that server. Furthermore, that same
file could be replicated to other servers (to make it more resistant file could be replicated to other servers (to make it more resistant
skipping to change at page 4, line 27 skipping to change at page 4, line 33
Key header field (Section 4) can be included to describe how the Key header field (Section 4) can be included to describe how the
content encryption key is derived or retrieved. content encryption key is derived or retrieved.
The "aesgcm" content-coding uses a single fixed set of encryption The "aesgcm" content-coding uses a single fixed set of encryption
primitives. Cipher suite agility is achieved by defining a new primitives. Cipher suite agility is achieved by defining a new
content-coding scheme. This ensures that only the HTTP Accept- content-coding scheme. This ensures that only the HTTP Accept-
Encoding header field is necessary to negotiate the use of Encoding header field is necessary to negotiate the use of
encryption. encryption.
The "aesgcm" content-coding uses a fixed record size. The resulting The "aesgcm" content-coding uses a fixed record size. The resulting
encoding is a series of fixed-size records, with a final record that encoding is either a single record, or a series of fixed-size
is one or more octets shorter than a fixed sized record. records. The final record, or a lone record, MUST be shorter than
the fixed record size.
+------+ input of between rs-65537 +-----------+ content is rs octets minus padding
| data | and rs-2 octets | data | of between 2 and 65537 octets;
+------+ (one fewer for the last record) +-----------+ the last record is smaller
| |
v v
+-----+-----------+ +-----+-----------+ add padding to get rs octets;
| pad | data | add padding to form plaintext | pad | data | the last record contains
+-----+-----------+ +-----+-----------+ up to rs minus 1 octets
| |
v v
+--------------------+ +--------------------+ encrypt with AEAD_AES_128_GCM;
| ciphertext | encrypt with AEAD_AES_128_GCM | ciphertext | final size is rs plus 16 octets
+--------------------+ expands by 16 octets +--------------------+ the last record is smaller
The record size determines the length of each portion of plaintext The record size determines the length of each portion of plaintext
that is enciphered, with the exception of the final record, which is that is enciphered, with the exception of the final record, which is
necessarily smaller. The record size defaults to 4096 octets, but necessarily smaller. The record size defaults to 4096 octets, but
can be changed using the "rs" parameter on the Encryption header can be changed using the "rs" parameter on the Encryption header
field. field.
AEAD_AES_128_GCM expands ciphertext to be 16 octets longer than its AEAD_AES_128_GCM produces ciphertext 16 octets longer than its input
input plaintext. Therefore, the length of each enciphered record plaintext. Therefore, the length of each enciphered record other
other than the last is equal to the value of the "rs" parameter plus than the last is equal to the value of the "rs" parameter plus 16
16 octets. A receiver MUST fail to decrypt if the final record octets. A receiver MUST fail to decrypt if the final record
ciphertext is 16 octets or less in size. Valid records always ciphertext is less than 18 octets in size. Valid records always
contain at least one byte of padding and a 16 octet authentication contain at least two octets of padding and a 16 octet authentication
tag. tag.
Each record contains between 2 and 65537 octets of padding, inserted Each record contains between 2 and 65537 octets of padding, inserted
into a record before the enciphered content. Padding consists of a into a record before the enciphered content. Padding consists of a
two octet unsigned integer in network byte order, followed that two octet unsigned integer in network byte order, followed that
number of zero-valued octets. A receiver MUST fail to decrypt if any number of zero-valued octets. A receiver MUST fail to decrypt if any
padding octet other than the first two are non-zero, or a record has padding octet other than the first two are non-zero, or a record has
more padding than the record size can accommodate. more padding than the record size can accommodate.
The nonce for each record is a 96-bit value constructed from the The nonce for each record is a 96-bit value constructed from the
skipping to change at page 5, line 36 skipping to change at page 5, line 44
prevent an attacker from truncating a stream, an encoder MUST append prevent an attacker from truncating a stream, an encoder MUST append
a record that contains only padding and is smaller than the full a record that contains only padding and is smaller than the full
record size if the final record ends on a record boundary. A record size if the final record ends on a record boundary. A
receiver MUST treat the stream as failed due to truncation if the receiver MUST treat the stream as failed due to truncation if the
final record is the full record size. final record is the full record size.
A consequence of this record structure is that range requests A consequence of this record structure is that range requests
[RFC7233] and random access to encrypted payload bodies are possible [RFC7233] and random access to encrypted payload bodies are possible
at the granularity of the record size. However, without data from at the granularity of the record size. However, without data from
adjacent ranges, partial records cannot be used. Thus, it is best if adjacent ranges, partial records cannot be used. Thus, it is best if
records start and end on multiples of the record size, plus the 16 range requests start and end on multiples of the record size, plus
octet authentication tag size. the 16 octet authentication tag size.
Selecting the record size most appropriate for a given situation
requires a trade-off. A smaller record size allows decrypted octets
to be released more rapidly, which can be appropriate for
applications that depend on responsiveness. Smaller records also
reduce the additional data required if random access into the
ciphertext is needed. Applications that depend on being able to pad
by arbitrary amounts cannot increase the record size beyond 65537
octets.
Applications that don't depending on streaming, random access, or
arbitrary padding can use larger records, or even a single record. A
larger record size reduces the processing and data overheads.
3. The Encryption HTTP Header Field 3. The Encryption HTTP Header Field
The "Encryption" HTTP header field describes the encrypted content The "Encryption" HTTP header field describes the encrypted content
encoding(s) that have been applied to a payload body, and therefore encoding(s) that have been applied to a payload body, and therefore
how those content encoding(s) can be removed. how those content encoding(s) can be removed.
The "Encryption" header field uses the extended ABNF syntax defined The "Encryption" header field uses the extended ABNF syntax defined
in Section 1.2 of [RFC7230] and the "parameter" rule from [RFC7231] in Section 1.2 of [RFC7230] and the "parameter" and "OWS" rules from
[RFC7231].
Encryption = #encryption_params Encryption = #encryption_params
encryption_params = [ parameter *( ";" parameter ) ] encryption_params = [ parameter *( OWS ";" OWS parameter ) ]
If the payload is encrypted more than once (as reflected by having If the payload is encrypted more than once (as reflected by having
multiple content-codings that imply encryption), each application of multiple content-codings that imply encryption), each application of
the content encoding is reflected in the Encryption header field, in the content encoding is reflected in a separate Encryption header
the order in which they were applied. field value in the order in which they were applied.
Encryption header field values with multiple instances of the same Encryption header field values with multiple instances of the same
parameter name are invalid. parameter name are invalid.
The Encryption header MAY be omitted if the sender does not intend
for the immediate recipient to be able to decrypt the payload body.
Alternatively, the Encryption header field MAY be omitted if the
sender intends for the recipient to acquire the header field by other
means.
Servers processing PUT requests MUST persist the value of the Servers processing PUT requests MUST persist the value of the
Encryption header field, unless they remove the content-coding by Encryption header field, unless they remove the content-coding by
decrypting the payload. decrypting the payload.
3.1. Encryption Header Field Parameters 3.1. Encryption Header Field Parameters
The following parameters are used in determining the content The following parameters are used in determining the content
encryption key that is used for encryption: encryption key that is used for encryption:
keyid: The "keyid" parameter contains a string that identifies the keyid: The "keyid" parameter identifies the keying material that is
keying material that is used. The "keyid" parameter SHOULD be used. When the Crypto-Key header field is used, the "keyid"
included, unless key identification is guaranteed by other means. identifies a matching value in that field. The "keyid" parameter
The "keyid" parameter MUST be used if keying material included in MUST be used if keying material included in an Crypto-Key header
an Crypto-Key header field is needed to derive the content field is needed to derive the content encryption key. The "keyid"
encryption key. parameter can also be used to identify keys in an application-
specific fashion.
salt: The "salt" parameter contains a base64url-encoded octets salt: The "salt" parameter contains a base64url-encoded octets
[RFC7515] that is used as salt in deriving a unique content [RFC7515] that is used as salt in deriving a unique content
encryption key (see Section 3.2). The "salt" parameter MUST be encryption key (see Section 3.2). The "salt" parameter MUST be
present, and MUST be exactly 16 octets long when decoded. The present, and MUST be exactly 16 octets long when decoded. The
"salt" parameter MUST NOT be reused for two different payload "salt" parameter MUST NOT be reused for two different payload
bodies that have the same input keying material; generating a bodies that have the same input keying material; generating a
random salt for every application of the content encoding ensures random salt for every application of the content encoding ensures
that content encryption key reuse is highly unlikely. that content encryption key reuse is highly unlikely.
rs: The "rs" parameter contains a positive decimal integer that rs: The "rs" parameter contains a positive decimal integer that
describes the record size in octets. This value MUST be greater describes the record size in octets. This value MUST be greater
than 1. If the "rs" parameter is absent, the record size defaults than 1. For the "aesgcm" content encoding, this value MUST NOT be
to 4096 octets. greater than 2^36-31 (see Section 6.2). The "rs" parameter is
optional. If the "rs" parameter is absent, the record size
defaults to 4096 octets.
3.2. Content Encryption Key Derivation 3.2. Content Encryption Key Derivation
In order to allow the reuse of keying material for multiple different In order to allow the reuse of keying material for multiple different
HTTP messages, a content encryption key is derived for each message. HTTP messages, a content encryption key is derived for each message.
The content encryption key is derived from the decoded value of the The content encryption key is derived from the decoded value of the
"salt" parameter using the HMAC-based key derivation function (HKDF) "salt" parameter using the HMAC-based key derivation function (HKDF)
described in [RFC5869] using the SHA-256 hash algorithm [FIPS180-4]. described in [RFC5869] using the SHA-256 hash algorithm [FIPS180-4].
The decoded value of the "salt" parameter is the salt input to HKDF The decoded value of the "salt" parameter is the salt input to HKDF
function. The keying material identified by the "keyid" parameter is function. The keying material identified by the "keyid" parameter is
the input keying material (IKM) to HKDF. Input keying material can the input keying material (IKM) to HKDF. Input keying material can
either be prearranged, or can be described using the Crypto-Key either be prearranged, or can be described using the Crypto-Key
header field (Section 4). The first step of HKDF is therefore: header field (Section 4). The extract phase of HKDF therefore
produces a pseudorandom key (PRK) as follows:
PRK = HMAC-SHA-256(salt, IKM) PRK = HMAC-SHA-256(salt, IKM)
The info parameter to HKDF is set to the ASCII-encoded string The info parameter to HKDF is set to the ASCII-encoded string
"Content-Encoding: aesgcm", a single zero octet and an optional "Content-Encoding: aesgcm", a single zero octet and an optional
context string: context string:
cek_info = "Content-Encoding: aesgcm" || 0x00 || context cek_info = "Content-Encoding: aesgcm" || 0x00 || context
Unless otherwise specified, the context is a zero length octet Unless otherwise specified, the context is a zero length octet
sequence. Specifications that use this content encoding MAY specify sequence. Specifications that use this content encoding MAY specify
the use of an expanded context to cover additional inputs in the key the use of an expanded context to cover additional inputs in the key
derivation. derivation.
AEAD_AES_128_GCM requires a 16 octet (128 bit) content encryption AEAD_AES_128_GCM requires a 16 octet (128 bit) content encryption key
key, so the length (L) parameter to HKDF is 16. The second step of (CEK), so the length (L) parameter to HKDF is 16. The second step of
HKDF can therefore be simplified to the first 16 octets of a single HKDF can therefore be simplified to the first 16 octets of a single
HMAC: HMAC:
CEK = HMAC-SHA-256(PRK, cek_info || 0x01) CEK = HMAC-SHA-256(PRK, cek_info || 0x01)
3.3. Nonce Derivation 3.3. Nonce Derivation
The nonce input to AEAD_AES_128_GCM is constructed for each record. The nonce input to AEAD_AES_128_GCM is constructed for each record.
The nonce for each record is a 12 octet (96 bit) value is produced The nonce for each record is a 12 octet (96 bit) value is produced
from the record sequence number and a value derived from the input from the record sequence number and a value derived from the input
skipping to change at page 8, line 23 skipping to change at page 8, line 37
The result is combined with the record sequence number - using The result is combined with the record sequence number - using
exclusive or - to produce the nonce. The record sequence number exclusive or - to produce the nonce. The record sequence number
(SEQ) is a 96-bit unsigned integer in network byte order that starts (SEQ) is a 96-bit unsigned integer in network byte order that starts
at zero. at zero.
Thus, the final nonce for each record is a 12 octet value: Thus, the final nonce for each record is a 12 octet value:
NONCE = HMAC-SHA-256(PRK, nonce_info || 0x01) XOR SEQ NONCE = HMAC-SHA-256(PRK, nonce_info || 0x01) XOR SEQ
This nonce construction prevents removal or reordering of records.
However, it permits truncation of the tail of the sequence (see
Section 2 for how this is avoided).
4. Crypto-Key Header Field 4. Crypto-Key Header Field
An Crypto-Key header field can be used to describe the input keying A Crypto-Key header field can be used to describe the input keying
material used in the Encryption header field. material used in the Encryption header field.
The Crypto-Key header field uses the extended ABNF syntax defined in The Crypto-Key header field uses the extended ABNF syntax defined in
Section 1.2 of [RFC7230] and the "parameter" rule from [RFC7231]. Section 1.2 of [RFC7230] and the "parameter" and "OWS" rules from
[RFC7231].
Crypto-Key = #crypto_key_params Crypto-Key = #crypto_key_params
crypto_key_params = [ parameter *( ";" parameter ) ] crypto_key_params = [ parameter *( OWS ";" OWS parameter ) ]
keyid: The "keyid" parameter corresponds to the "keyid" parameter in keyid: The "keyid" parameter corresponds to the "keyid" parameter in
the Encryption header field. the Encryption header field.
aesgcm: The "aesgcm" parameter contains the base64url-encoded octets aesgcm: The "aesgcm" parameter contains the base64url-encoded octets
[RFC7515] of the input keying material. [RFC7515] of the input keying material for the "aesgcm" content
encoding.
dh: The "dh" parameter contains an ephemeral Diffie-Hellman share. dh: The "dh" parameter contains an ephemeral Diffie-Hellman share.
This form of the header field can be used to encrypt content for a This form of the header field can be used to encrypt content for a
specific recipient. specific recipient.
Crypto-Key header field values with multiple instances of the same Crypto-Key header field values with multiple instances of the same
parameter name are invalid. parameter name are invalid.
The input keying material used by the key derivation (see The input keying material used by the key derivation (see
Section 3.2) can be determined based on the information in the Section 3.2) can be determined based on the information in the
skipping to change at page 11, line 39 skipping to change at page 12, line 11
and filename safe variant of base64 [RFC4648]. This includes the and filename safe variant of base64 [RFC4648]. This includes the
bodies of requests. Whitespace in these values is added to fit bodies of requests. Whitespace in these values is added to fit
formatting constraints. formatting constraints.
5.1. Successful GET Response 5.1. Successful GET Response
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/octet-stream Content-Type: application/octet-stream
Content-Encoding: aesgcm Content-Encoding: aesgcm
Connection: close Connection: close
Encryption: keyid="http://example.org/bob/keys/123"; Encryption: keyid="bob/keys/123";
salt="XZwpw6o37R-6qoZjw6KwAw" salt="XZwpw6o37R-6qoZjw6KwAw"
[encrypted payload] [encrypted payload]
Here, a successful HTTP GET response has been encrypted using input Here, a successful HTTP GET response has been encrypted using input
keying material that is identified by a URI. keying material that is identified by a URI.
Note that the media type has been changed to "application/octet- Note that the media type has been changed to "application/octet-
stream" to avoid exposing information about the content. stream" to avoid exposing information about the content.
5.2. Encryption and Compression 5.2. Encryption and Compression
In this example, a response is first compressed, then encrypted. In this example, a response is first compressed, then encrypted.
Note that this particular encoding might compromise confidentiality Note that this particular encoding might compromise confidentiality
if the contents of the response could be influenced by an attacker. if the contents of the response could be influenced by an attacker.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/html Content-Type: text/html
Content-Encoding: gzip, aesgcm Content-Encoding: gzip, aesgcm
Transfer-Encoding: chunked Transfer-Encoding: chunked
Encryption: keyid="mailto:me@example.com"; Encryption: keyid="me@example.com";
salt="m2hJ_NttRtFyUiMRPwfpHA" salt="m2hJ_NttRtFyUiMRPwfpHA"
[encrypted payload] [encrypted payload]
5.3. Encryption with More Than One Key 5.3. Encryption with More Than One Key
Here, a PUT request has been encrypted twice with different input Here, a PUT request has been encrypted twice with different input
keying material; decrypting twice is necessary to read the content. keying material; decrypting twice is necessary to read the content.
The outer layer of encryption uses a 1200 octet record size. The outer layer of encryption uses a 1200 octet record size.
PUT /thing HTTP/1.1 PUT /thing HTTP/1.1
Host: storage.example.com Host: storage.example.com
Content-Type: application/http Content-Type: application/http
Content-Encoding: aesgcm, aesgcm Content-Encoding: aesgcm, aesgcm
Content-Length: 1235 Content-Length: 1235
Encryption: keyid="mailto:me@example.com"; Encryption: keyid="mailto:me@example.com";
salt="NfzOeuV5USPRA-n_9s1Lag", salt="NfzOeuV5USPRA-n_9s1Lag",
keyid="http://example.org/bob/keys/123"; keyid="bob/keys/123";
salt="bDMSGoc2uobK_IhavSHsHA"; rs=1200 salt="bDMSGoc2uobK_IhavSHsHA"; rs=1200
[encrypted payload] [encrypted payload]
5.4. Encryption with Explicit Key 5.4. Encryption with Explicit Key
This example shows the UTF-8 encoded string "I am the walrus" This example shows the UTF-8 encoded string "I am the walrus"
encrypted using an directly provided value for the input keying encrypted using an directly provided value for the input keying
material. The content body contains a single record only and is material. The content body contains a single record only and is
shown here using base64url encoding for presentation reasons. shown here using base64url encoding for presentation reasons.
skipping to change at page 15, line 23 skipping to change at page 16, line 5
If a content encryption key is reused - that is, if input keying If a content encryption key is reused - that is, if input keying
material and salt are reused - this could expose the plaintext and material and salt are reused - this could expose the plaintext and
the authentication key, nullifying the protection offered by the authentication key, nullifying the protection offered by
encryption. Thus, if the same input keying material is reused, then encryption. Thus, if the same input keying material is reused, then
the salt parameter MUST be unique each time. This ensures that the the salt parameter MUST be unique each time. This ensures that the
content encryption key is not reused. An implementation SHOULD content encryption key is not reused. An implementation SHOULD
generate a random salt parameter for every message; a counter could generate a random salt parameter for every message; a counter could
achieve the same result. achieve the same result.
6.2. Content Integrity 6.2. Data Encryption Limits
There are limits to the data that AEAD_AES_128_GCM can encipher. The
maximum record size is 2^36-31 [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 [AEBounds].
If rs is a multiple of 16 octets, this means 398 terabytes can be
encrypted safely, including padding. However, if the record size is
a multiple of 16 octets, the total amount of data that can be safely
encrypted is reduced. 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.
6.3. Content Integrity
This mechanism only provides content origin authentication. The This mechanism only provides content origin authentication. The
authentication tag only ensures that an entity with access to the authentication tag only ensures that an entity with access to the
content encryption key produced the encrypted data. content encryption key produced the encrypted data.
Any entity with the content encryption key can therefore produce Any entity with the content encryption key can therefore produce
content that will be accepted as valid. This includes all recipients content that will be accepted as valid. This includes all recipients
of the same HTTP message. of the same HTTP message.
Furthermore, any entity that is able to modify both the Encryption Furthermore, any entity that is able to modify both the Encryption
header field and the HTTP message body can replace the contents. header field and the HTTP message body can replace the contents.
Without the content encryption key or the input keying material, Without the content encryption key or the input keying material,
modifications to or replacement of parts of a payload body are not modifications to or replacement of parts of a payload body are not
possible. possible.
6.3. Leaking Information in Headers 6.4. Leaking Information in Headers
Because only the payload body is encrypted, information exposed in Because only the payload body is encrypted, information exposed in
header fields is visible to anyone who can read the HTTP message. header fields is visible to anyone who can read the HTTP message.
This could expose side-channel information. This could expose side-channel information.
For example, the Content-Type header field can leak information about For example, the Content-Type header field can leak information about
the payload body. the payload body.
There are a number of strategies available to mitigate this threat, There are a number of strategies available to mitigate this threat,
depending upon the application's threat model and the users' depending upon the application's threat model and the users'
skipping to change at page 16, line 22 skipping to change at page 17, line 17
in other representations, etc.), omit the relevant headers, and/ in other representations, etc.), omit the relevant headers, and/
or normalize them. In the case of Content-Type, this could be or normalize them. In the case of Content-Type, this could be
accomplished by always sending Content-Type: application/octet- accomplished by always sending Content-Type: application/octet-
stream (the most generic media type), or no Content-Type at all. stream (the most generic media type), or no Content-Type at all.
3. If it is considered sensitive information and it is not possible 3. If it is considered sensitive information and it is not possible
to convey it elsewhere, encapsulate the HTTP message using the to convey it elsewhere, encapsulate the HTTP message using the
application/http media type (Section 8.3.2 of [RFC7230]), application/http media type (Section 8.3.2 of [RFC7230]),
encrypting that as the payload of the "outer" message. encrypting that as the payload of the "outer" message.
6.4. Poisoning Storage 6.5. Poisoning Storage
This mechanism only offers encryption of content; it does not perform This mechanism only offers encryption of content; it does not perform
authentication or authorization, which still needs to be performed authentication or authorization, which still needs to be performed
(e.g., by HTTP authentication [RFC7235]). (e.g., by HTTP authentication [RFC7235]).
This is especially relevant when a HTTP PUT request is accepted by a This is especially relevant when a HTTP PUT request is accepted by a
server; if the request is unauthenticated, it becomes possible for a server; if the request is unauthenticated, it becomes possible for a
third party to deny service and/or poison the store. third party to deny service and/or poison the store.
6.5. Sizing and Timing Attacks 6.6. Sizing and Timing Attacks
Applications using this mechanism need to be aware that the size of Applications using this mechanism need to be aware that the size of
encrypted messages, as well as their timing, HTTP methods, URIs and encrypted messages, as well as their timing, HTTP methods, URIs and
so on, may leak sensitive information. so on, may leak sensitive information.
This risk can be mitigated through the use of the padding that this This risk can be mitigated through the use of the padding that this
mechanism provides. Alternatively, splitting up content into mechanism provides. Alternatively, splitting up content into
segments and storing the separately might reduce exposure. HTTP/2 segments and storing the separately might reduce exposure. HTTP/2
[RFC7540] combined with TLS [RFC5246] might be used to hide the size [RFC7540] combined with TLS [RFC5246] might be used to hide the size
of individual messages. of individual messages.
7. IANA Considerations 7. IANA Considerations
7.1. The "aesgcm" HTTP Content Encoding 7.1. The "aesgcm" HTTP Content Encoding
This memo registers the "encrypted" HTTP content-coding in the HTTP This memo registers the "aesgcm" HTTP content-coding in the HTTP
Content Codings Registry, as detailed in Section 2. Content Codings Registry, as detailed in Section 2.
o Name: aesgcm o Name: aesgcm
o Description: AES-GCM encryption with a 128-bit content encryption o Description: AES-GCM encryption with a 128-bit content encryption
key key
o Reference: this specification o Reference: this specification
7.2. Encryption Header Fields 7.2. Encryption Header Fields
This memo registers the "Encryption" HTTP header field in the This memo registers the "Encryption" HTTP header field in the
Permanent Message Header Registry, as detailed in Section 3. Permanent Message Header Registry, as detailed in Section 3.
skipping to change at page 20, line 36 skipping to change at page 21, line 36
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>. <http://www.rfc-editor.org/info/rfc7231>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>. 2015, <http://www.rfc-editor.org/info/rfc7515>.
8.2. Informative References 8.2. Informative References
[AEBounds]
Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", March 2016,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[FIPS186] National Institute of Standards and Technology (NIST), [FIPS186] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", NIST PUB 186-4 , July "Digital Signature Standard (DSS)", NIST PUB 186-4 , July
2013. 2013.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007, DOI 10.17487/RFC4880, November 2007,
<http://www.rfc-editor.org/info/rfc4880>. <http://www.rfc-editor.org/info/rfc4880>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
 End of changes. 42 change blocks. 
87 lines changed or deleted 131 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/