draft-ietf-httpbis-encryption-encoding-05.txt   draft-ietf-httpbis-encryption-encoding-06.txt 
HTTP Working Group M. Thomson HTTP Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track December 21, 2016 Intended status: Standards Track December 22, 2016
Expires: June 24, 2017 Expires: June 25, 2017
Encrypted Content-Encoding for HTTP Encrypted Content-Encoding for HTTP
draft-ietf-httpbis-encryption-encoding-05 draft-ietf-httpbis-encryption-encoding-06
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 June 24, 2017. This Internet-Draft will expire on June 25, 2017.
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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
2. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . . . 3 2. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . . . 3
2.1. Encryption Content Coding Header . . . . . . . . . . . . 5 2.1. Encryption Content Coding Header . . . . . . . . . . . . 5
2.2. Content Encryption Key Derivation . . . . . . . . . . . . 6 2.2. Content Encryption Key Derivation . . . . . . . . . . . . 6
2.3. Nonce Derivation . . . . . . . . . . . . . . . . . . . . 6 2.3. Nonce Derivation . . . . . . . . . . . . . . . . . . . . 6
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Encryption of a Response . . . . . . . . . . . . . . . . 7 3.1. Encryption of a Response . . . . . . . . . . . . . . . . 7
3.2. Encryption with Multiple Records . . . . . . . . . . . . 8 3.2. Encryption with Multiple Records . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.1. Key and Nonce Reuse . . . . . . . . . . . . . . . . . . . 9 4.1. Key and Nonce Reuse . . . . . . . . . . . . . . . . . . . 9
4.2. Data Encryption Limits . . . . . . . . . . . . . . . . . 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.4. Leaking Information in Headers . . . . . . . . . . . . . 10
4.5. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 10 4.5. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 11
4.6. Sizing and Timing Attacks . . . . . . . . . . . . . . . . 11 4.6. Sizing and Timing Attacks . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . 11 5.1. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. JWE Mapping . . . . . . . . . . . . . . . . . . . . 13 Appendix A. JWE Mapping . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
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.
skipping to change at page 4, line 15 skipping to change at page 4, line 15
The "aes128gcm" content coding uses a fixed record size. The final The "aes128gcm" content coding uses a fixed record size. The final
encoding consists of a header (see Section 2.1), zero or more fixed encoding consists of a header (see Section 2.1), zero or more fixed
size encrypted records, and a partial record. The partial record size encrypted records, and a partial record. The partial record
MUST be shorter than the fixed record size. MUST be shorter than the fixed record size.
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 ("rs") is included in the necessarily smaller. The record size ("rs") is included in the
content coding header (see Section 2.1). content coding header (see Section 2.1).
+-----------+ content is rs octets minus padding +-----------+ content of rs octets minus padding
| data | of between 2 and 65537 octets; | data | less padding (2-65537) and tag (16);
+-----------+ the last record is smaller +-----------+ the last record is smaller
| |
v v
+-----+-----------+ add padding to get rs octets; +-----+-----------+ add padding to get rs-16 octets;
| pad | data | the last record contains | pad | data | the last record contains
+-----+-----------+ up to rs minus 1 octets +-----+-----------+ up to rs minus 17 octets
| |
v v
+--------------------+ encrypt with AEAD_AES_128_GCM; +--------------------+ encrypt with AEAD_AES_128_GCM;
| ciphertext | final size is rs plus 16 octets | ciphertext | final size is rs;
+--------------------+ the last record is smaller +--------------------+ the last record is smaller
AEAD_AES_128_GCM produces ciphertext 16 octets longer than its input AEAD_AES_128_GCM produces ciphertext 16 octets longer than its input
plaintext. Therefore, the length of each enciphered record other plaintext. Therefore, the unencrypted content of each record is
than the last is equal to the value of the "rs" parameter plus 16 shorter than the record size by 16 octets. If the final record ends
octets. If the final record ends on a record boundary, the encoder on a record boundary, the encoder MUST append a record that contains
MUST append a record that contains contains only padding and is contains only padding and is smaller than the full record size. A
smaller than the full record size. A receiver MUST fail to decrypt receiver MUST fail to decrypt if the final record ciphertext is less
if the final record ciphertext is less than 18 octets in size or than 18 octets in size or equal to the record size. Valid records
equal to the record size plus 16 (that is, the size of a full always contain at least a padding length of 2 octets and a 16 octet
encrypted record). Valid records always contain at least two octets authentication tag.
of padding and a 16 octet authentication tag.
Each record contains a 2 octet padding length field and between 0 and Each record contains a 2 octet padding length and between 0 and 65535
65535 octets of padding, inserted into a record before the enciphered octets of padding, inserted into a record before the content. The
content. The padding length is a two octet unsigned integer in padding length is a two octet unsigned integer in network byte order;
network byte order; padding is that number of zero-valued octets. A padding is that number of zero-valued octets. A receiver MUST fail
receiver MUST fail to decrypt if any padding octet is non-zero, or a to decrypt if any padding octet is non-zero, or a record has more
record has more padding than the record size can accommodate. 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
record sequence number and the input keying material. Nonce record sequence number and the input keying material. Nonce
derivation is covered in Section 2.3. derivation is covered in Section 2.3.
The additional data passed to each invocation of AEAD_AES_128_GCM is The additional data passed to each invocation of AEAD_AES_128_GCM is
a zero-length octet sequence. a zero-length octet sequence.
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
skipping to change at page 5, line 50 skipping to change at page 5, line 47
"aes128gcm" content coding header. The same "salt" parameter "aes128gcm" content coding header. The same "salt" parameter
value MUST NOT be reused for two different payload bodies that value MUST NOT be reused for two different payload bodies that
have the same input keying material; generating a random salt for have the same input keying material; generating a random salt for
every application of the content coding ensures that content every application of the content coding ensures that content
encryption key reuse is highly unlikely. encryption key reuse is highly unlikely.
rs: The "rs" or record size parameter contains an unsigned 32-bit rs: The "rs" or record size parameter contains an unsigned 32-bit
integer in network byte order that describes the record size in integer in network byte order that describes the record size in
octets. Note that it is therefore impossible to exceed the octets. Note that it is therefore impossible to exceed the
2^36-31 limit on plaintext input to AEAD_AES_128_GCM. Values 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 keyid: The "keyid" parameter can be used to identify the keying
material that is used. Recipients that receive a message are material that is used. Recipients that receive a message are
expected to know how to retrieve keys; the "keyid" parameter might 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 2.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 "salt" parameter using The content encryption key is derived from the "salt" parameter using
the HMAC-based key derivation function (HKDF) described in [RFC5869] the HMAC-based key derivation function (HKDF) described in [RFC5869]
using the SHA-256 hash algorithm [FIPS180-4]. using the SHA-256 hash algorithm [FIPS180-4].
The value of the "salt" parameter is the salt input to HKDF function. The value of the "salt" parameter is the salt input to HKDF function.
skipping to change at page 8, line 30 skipping to change at page 8, line 30
salt (from header) = sJvlboCWzB5jr8hI_q9cOQ salt (from header) = sJvlboCWzB5jr8hI_q9cOQ
PRK = MLAQxt_DHjM15cdlyU1oUnjq7TFlzToGTkdRmvvxVBw PRK = MLAQxt_DHjM15cdlyU1oUnjq7TFlzToGTkdRmvvxVBw
CEK = v31u7VGV3soO3wNaMaIdhg CEK = v31u7VGV3soO3wNaMaIdhg
NONCE = XOaygzko98zjUFTJ NONCE = XOaygzko98zjUFTJ
plaintext = AABJIGFtIHRoZSB3YWxydXM plaintext = AABJIGFtIHRoZSB3YWxydXM
3.2. Encryption with Multiple Records 3.2. Encryption with Multiple Records
This example shows the same message with input keying material of This example shows the same message with input keying material of
"BO3ZVPxUlnLORbVGMpbT1Q". In this example, the plaintext is split "BO3ZVPxUlnLORbVGMpbT1Q". In this example, the plaintext is split
into records of 10 octets each (that is, the "rs" field in the header into records of 26 octets each (that is, the "rs" field in the header
is 10). The first record includes a single octet of padding. This 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 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 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 record boundary, forcing the creation of a third record that contains
only two octets of the padding length. only two octets of the padding length.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 93 Content-Length: 93
Content-Encoding: aes128gcm Content-Encoding: aes128gcm
uNCkWiNYzKTnBN9ji3-qWAAAAAoCYTGHOqYFz-0in3dpb-VE2GfBngkaPy6bZus_ uNCkWiNYzKTnBN9ji3-qWAAAABoCYTGHOqYFz-0in3dpb-VE2GfBngkaPy6bZus_
qLF79s6zQyTSsA0iLOKyd3JqVIwprNzVatRCWZGUx_qsFbJBCQu62RqQuR2d qLF79s6zQyTSsA0iLOKyd3JqVIwprNzVatRCWZGUx_qsFbJBCQu62RqQuR2d
4. Security Considerations 4. Security Considerations
This mechanism assumes the presence of a key management framework This mechanism assumes the presence of a key management framework
that is used to manage the distribution of keys between valid senders that is used to manage the distribution of keys between valid senders
and receivers. Defining key management is part of composing this and receivers. Defining key management is part of composing this
mechanism into a larger application, protocol, or framework. mechanism into a larger application, protocol, or framework.
Implementation of cryptography - and key management in particular - Implementation of cryptography - and key management in particular -
skipping to change at page 9, line 41 skipping to change at page 9, line 41
There are limits to the data that AEAD_AES_128_GCM can encipher. The 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" 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 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 limit for a single application of AEAD_AES_128_GCM is not reached
[RFC5116]. In order to preserve a 2^-40 probability of [RFC5116]. In order to preserve a 2^-40 probability of
indistinguishability under chosen plaintext attack (IND-CPA), the indistinguishability under chosen plaintext attack (IND-CPA), the
total amount of plaintext that can be enciphered MUST be less than total amount of plaintext that can be enciphered MUST be less than
2^44.5 blocks of 16 octets [AEBounds]. 2^44.5 blocks of 16 octets [AEBounds].
If rs is a multiple of 16 octets, this means 398 terabytes can be If the record size is a multiple of 16 octets, this means 398
encrypted safely, including padding and overhead. However, if the terabytes can be encrypted safely, including padding and overhead.
record size is not a multiple of 16 octets, the total amount of data However, if the record size is not a multiple of 16 octets, the total
that can be safely encrypted is reduced proportionally. The worst amount of data that can be safely encrypted is reduced because
case is a record size of 3 octets, for which at most 74 terabytes of partial AES blocks are encrypted. The worst case is a record size of
plaintext can be encrypted, of which at least two-thirds is padding. 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 4.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.
skipping to change at page 12, line 10 skipping to change at page 12, line 20
Department of Commerce, National., "NIST FIPS 180-4, Department of Commerce, National., "NIST FIPS 180-4,
Secure Hash Standard", March 2012, Secure Hash Standard", March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>. <http://www.rfc-editor.org/info/rfc5116>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>. <http://www.rfc-editor.org/info/rfc5869>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
 End of changes. 18 change blocks. 
39 lines changed or deleted 45 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/