draft-ietf-httpbis-encryption-encoding-08.txt   draft-ietf-httpbis-encryption-encoding-latest.txt 
HTTP Working Group M. Thomson HTTP Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track March 2, 2017 Intended status: Standards Track March 24, 2017
Expires: September 3, 2017 Expires: September 25, 2017
Encrypted Content-Encoding for HTTP Encrypted Content-Encoding for HTTP
draft-ietf-httpbis-encryption-encoding-08 draft-ietf-httpbis-encryption-encoding-latest
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 3, 2017. This Internet-Draft will expire on September 25, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 35 skipping to change at page 2, line 35
4.2. Key and Nonce Reuse . . . . . . . . . . . . . . . . . . . 9 4.2. Key and Nonce Reuse . . . . . . . . . . . . . . . . . . . 9
4.3. Data Encryption Limits . . . . . . . . . . . . . . . . . 9 4.3. Data Encryption Limits . . . . . . . . . . . . . . . . . 9
4.4. Content Integrity . . . . . . . . . . . . . . . . . . . . 10 4.4. Content Integrity . . . . . . . . . . . . . . . . . . . . 10
4.5. Leaking Information in Header Fields . . . . . . . . . . 10 4.5. Leaking Information in Header Fields . . . . . . . . . . 10
4.6. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 11 4.6. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 11
4.7. Sizing and Timing Attacks . . . . . . . . . . . . . . . . 11 4.7. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. JWE Mapping . . . . . . . . . . . . . . . . . . . . 14 Appendix A. JWE Mapping . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 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.
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 3, line 35 skipping to change at page 3, line 35
uses content encryption. How clients and servers acquire and uses content encryption. How clients and servers acquire and
identify keys will depend on the use case. In particular, a key identify keys will depend on the use case. In particular, a key
management system is not described. management system is not described.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Base64url encoding is defined in Section 2 of [RFC7515].
2. The "aes128gcm" HTTP Content Coding 2. The "aes128gcm" HTTP Content Coding
The "aes128gcm" HTTP content coding indicates that a payload has been The "aes128gcm" HTTP content coding indicates that a payload has been
encrypted using Advanced Encryption Standard (AES) in Galois/Counter encrypted using Advanced Encryption Standard (AES) in Galois/Counter
Mode (GCM) as identified as AEAD_AES_128_GCM in [RFC5116], Mode (GCM) as identified as AEAD_AES_128_GCM in [RFC5116],
Section 5.1. The AEAD_AES_128_GCM algorithm uses a 128 bit content Section 5.1. The AEAD_AES_128_GCM algorithm uses a 128 bit content
encryption key. encryption key.
Using this content coding requires knowledge of a key. How this key Using this content coding requires knowledge of a key. How this key
is acquired is not defined in this document. is acquired is not defined in this document.
skipping to change at page 7, line 22 skipping to change at page 7, line 22
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. This nonce construction prevents removal or reordering of records.
However, it permits truncation of the tail of the sequence (see However, it permits truncation of the tail of the sequence (see
Section 2 for how this is avoided). Section 2 for how this is avoided).
3. Examples 3. Examples
This section shows a few examples of the encrypted content coding. This section shows a few examples of the encrypted content coding.
Note: All binary values in the examples in this section use base64url Note: All binary values in the examples in this section use Base 64
encoding [RFC7515]. This includes the bodies of requests. Encoding with URL and Filename Safe Alphabet [RFC4648]. This
Whitespace and line wrapping is added to fit formatting constraints. includes the bodies of requests. Whitespace and line wrapping is
added to fit formatting constraints.
3.1. Encryption of a Response 3.1. Encryption of a Response
Here, a successful HTTP GET response has been encrypted. This uses a Here, a successful HTTP GET response has been encrypted. This uses a
record size of 4096 and no padding (just the single octet padding record size of 4096 and no padding (just the single octet padding
delimiter), so only a partial record is present. The input keying delimiter), so only a partial record is present. The input keying
material is identified by an empty string (that is, the "keyid" field material is identified by an empty string (that is, the "keyid" field
in the header is zero octets in length). in the header is zero octets in length).
The encrypted data in this example is the UTF-8 encoded string "I am The encrypted data in this example is the UTF-8 encoded string "I am
skipping to change at page 12, line 46 skipping to change at page 12, line 46
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
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
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>.
6.2. Informative References 6.2. Informative References
[AEBounds] [AEBounds]
Luykx, A. and K. Paterson, "Limits on Authenticated Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", March 2016, Encryption Use in TLS", March 2016,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>. <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[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>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
 End of changes. 9 change blocks. 
16 lines changed or deleted 15 lines changed or added

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