doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc8188.txt b/doc/rfc/rfc8188.txt
new file mode 100644
index 0000000..746e93b
--- /dev/null
+++ b/doc/rfc/rfc8188.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        M. Thomson
+Request for Comments: 8188                                       Mozilla
+Category: Standards Track                                      June 2017
+ISSN: 2070-1721
+
+
+                  Encrypted Content-Encoding for HTTP
+
+Abstract
+
+   This memo introduces a content coding for HTTP that allows message
+   payloads to be encrypted.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8188.
+
+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
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+Thomson                      Standards Track                    [Page 1]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
+   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.  Automatic Decryption  . . . . . . . . . . . . . . . . . .   9
+     4.2.  Message Truncation  . . . . . . . . . . . . . . . . . . .   9
+     4.3.  Key and Nonce Reuse . . . . . . . . . . . . . . . . . . .   9
+     4.4.  Data Encryption Limits  . . . . . . . . . . . . . . . . .  10
+     4.5.  Content Integrity . . . . . . . . . . . . . . . . . . . .  10
+     4.6.  Leaking Information in Header Fields  . . . . . . . . . .  10
+     4.7.  Poisoning Storage . . . . . . . . . . . . . . . . . . . .  11
+     4.8.  Sizing and Timing Attacks . . . . . . . . . . . . . . . .  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  . . . . . . . . . . . . . . . . . . . .  15
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16
+
+1.  Introduction
+
+   It is sometimes desirable to encrypt the contents of an HTTP message
+   (request or response) so that when the payload is stored (e.g., with
+   an 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
+   file could be replicated to other servers (to make it more resistant
+   to server or network failure), downloaded by clients (to make it
+   available offline), etc., without exposing its contents.
+
+   These uses are not met by the use of Transport Layer Security (TLS)
+   [RFC5246], since it only encrypts the channel between the client and
+   server.
+
+   This document specifies a content coding (see Section 3.1.2 of
+   [RFC7231]) for HTTP to serve these and other use cases.
+
+
+
+
+Thomson                      Standards Track                    [Page 2]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+   This content coding is not a direct adaptation of message-based
+   encryption formats -- such as those that are described by [RFC4880],
+   [RFC5652], [RFC7516], and [XMLENC].  Those formats are not suited to
+   stream processing, which is necessary for HTTP.  The format described
+   here follows more closely to the lower-level constructs described in
+   [RFC5116].
+
+   To the extent that message-based encryption formats use the same
+   primitives, the format can be considered to be a sequence of
+   encrypted messages with a particular profile.  For instance,
+   Appendix A explains how the format is congruent with a sequence of
+   JSON Web Encryption [RFC7516] values with a fixed header.
+
+   This mechanism is likely only a small part of a larger design that
+   uses content encryption.  How clients and servers acquire and
+   identify keys will depend on the use case.  In particular, a key
+   management system is not described.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in BCP
+   14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  The "aes128gcm" HTTP Content Coding
+
+   The "aes128gcm" HTTP content coding indicates that a payload has been
+   encrypted using Advanced Encryption Standard (AES) in Galois/Counter
+   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-
+   encryption key.
+
+   Using this content coding requires knowledge of a key.  How this key
+   is acquired is not defined in this document.
+
+   The "aes128gcm" content coding uses a single fixed set of encryption
+   primitives.  Cipher agility is achieved by defining a new content-
+   coding scheme.  This ensures that only the HTTP Accept-Encoding
+   header field is necessary to negotiate the use of encryption.
+
+   The "aes128gcm" content coding uses a fixed record size.  The final
+   encoding consists of a header (see Section 2.1) and zero or more
+   fixed-size encrypted records; the final record can be smaller than
+   the record size.
+
+
+
+
+
+Thomson                      Standards Track                    [Page 3]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+   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 |       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.
+
+   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
+   at the granularity of the record size.  Partial records at the ends
+   of a range cannot be decrypted.  Thus, it is best if range requests
+   start and end on record boundaries.  However, note that random access
+
+
+
+
+Thomson                      Standards Track                    [Page 4]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+   to specific parts of encrypted data could be confounded by the
+   presence of padding.
+
+   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 don't depend on streaming, random access, or
+   arbitrary padding can use larger records, or even a single record.  A
+   larger record size reduces processing and data overheads.
+
+2.1.  Encryption Content-Coding Header
+
+   The content coding uses a header block that includes all parameters
+   needed to decrypt the content (other than the key).  The header block
+   is placed in the body of a message ahead of the sequence of records.
+
+   +-----------+--------+-----------+---------------+
+   | salt (16) | rs (4) | idlen (1) | keyid (idlen) |
+   +-----------+--------+-----------+---------------+
+
+   salt:  The "salt" parameter comprises the first 16 octets of the
+      "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 18 are invalid.
+
+   idlen:  The "idlen" parameter is an unsigned 8-bit integer that
+      defines the length of the "keyid" parameter.
+
+   keyid:  The "keyid" parameter can be used to identify the keying
+      material that is used.  This field is the length determined by the
+      "idlen" parameter.  Recipients that receive a message are expected
+      to know how to retrieve keys; the "keyid" parameter might be input
+      to that process.  A "keyid" parameter SHOULD be a UTF-8-encoded
+      [RFC3629] string, particularly where the identifier might need to
+      be rendered in a textual form.
+
+
+
+
+Thomson                      Standards Track                    [Page 5]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+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 the HKDF.  The
+   keying material identified by the "keyid" parameter is the input-
+   keying material (IKM) to HKDF.  Input-keying material is expected to
+   be provided to recipients separately.  The extract phase of HKDF,
+   therefore, produces a pseudorandom key (PRK) as follows:
+
+      PRK = HMAC-SHA-256 (salt, IKM)
+
+   The info parameter to HKDF is set to the ASCII-encoded string
+   "Content-Encoding: aes128gcm" and a single zero octet:
+
+      cek_info = "Content-Encoding: aes128gcm" || 0x00
+
+   Note(1):  Concatenation of octet sequences is represented by the "||"
+      operator.
+
+   Note(2):  The strings used here and in Section 2.3 do not include a
+      terminating 0x00 octet, as is used in some programming languages.
+
+   AEAD_AES_128_GCM requires a 16-octet (128-bit) content-encryption key
+   (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
+   HMAC:
+
+      CEK = HMAC-SHA-256(PRK, cek_info || 0x01)
+
+2.3.  Nonce Derivation
+
+   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 that is
+   derived from the record sequence number, input-keying material, and
+   "salt" parameter.
+
+   The input-keying material and "salt" parameter are input to HKDF with
+   different info and length (L) parameters.
+
+
+
+
+
+
+
+
+Thomson                      Standards Track                    [Page 6]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+   The length (L) parameter is 12 octets.  The info parameter for the
+   nonce is the ASCII-encoded string "Content-Encoding: nonce",
+   terminated by a single zero octet:
+
+      nonce_info = "Content-Encoding: nonce" || 0x00
+
+   The result is combined with the record sequence number -- using
+   exclusive or -- to produce the nonce.  The record sequence number
+   (SEQ) is a 96-bit unsigned integer in network byte order that starts
+   at zero.
+
+   Thus, the final nonce for each record is a 12-octet value:
+
+      NONCE = HMAC-SHA-256(PRK, nonce_info || 0x01) XOR SEQ
+
+   This nonce construction prevents removal or reordering of records.
+
+3.  Examples
+
+   This section shows a few examples of the encrypted-content coding.
+
+   Note: All binary values in the examples in this section use base64
+   encoding with URL and filename safe alphabet [RFC4648].  This
+   includes the bodies of requests.  Whitespace and line wrapping is
+   added to fit formatting constraints.
+
+3.1.  Encryption of a Response
+
+   Here, a successful HTTP GET response has been encrypted.  This uses a
+   record size of 4096 octets and no padding (just the single-octet
+   padding delimiter), so only a partial record is present.  The input-
+   keying material is identified by an empty string (that is, the
+   "keyid" field in the header is zero octets in length).
+
+   The encrypted data in this example is the UTF-8-encoded string "I am
+   the walrus".  The input-keying material is the value "yqdlZ-
+   tYemfogSmv7Ws5PQ" (in base64url).  The 54-octet content body contains
+   a single record and is shown here using 71 base64url characters for
+   presentation reasons.
+
+   HTTP/1.1 200 OK
+   Content-Type: application/octet-stream
+   Content-Length: 54
+   Content-Encoding: aes128gcm
+
+   I1BsxtFttlv3u_Oo94xnmwAAEAAA-NAVub2qFgBEuQKRapoZu-IxkIva3MEB1PD-
+   ly8Thjg
+
+
+
+
+Thomson                      Standards Track                    [Page 7]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+   Note that the media type has been changed to "application/octet-
+   stream" to avoid exposing information about the content.
+   Alternatively (and equivalently), the Content-Type header field can
+   be omitted.
+
+   Intermediate values for this example (all shown using base64url):
+
+   salt (from header) = I1BsxtFttlv3u_Oo94xnmw
+   PRK = zyeH5phsIsgUyd4oiSEIy35x-gIi4aM7y0hCF8mwn9g
+   CEK = _wniytB-ofscZDh4tbSjHw
+   NONCE = Bcs8gkIRKLI8GeI8
+   unencrypted data = SSBhbSB0aGUgd2FscnVzAg
+
+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 25 octets each (that is, the "rs" field in the header
+   is 25).  The first record includes one 0x00 padding octet.  This
+   means that there are 7 octets of message in the first record and 8 in
+   the second.  A key identifier of the UTF-8-encoded string "a1" is
+   also included in the header.
+
+   HTTP/1.1 200 OK
+   Content-Length: 73
+   Content-Encoding: aes128gcm
+
+   uNCkWiNYzKTnBN9ji3-qWAAAABkCYTHOG8chz_gnvgOqdGYovxyjuqRyJFjEDyoF
+   1Fvkj6hQPdPHI51OEUKEpgz3SsLWIqS_uA
+
+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 --
+   can be difficult.  For instance, implementations need to account for
+   the potential for exposing keying material on side channels, such as
+   might be exposed by the time it takes to perform a given operation.
+   The requirements for a good implementation of cryptographic
+   algorithms can change over time.
+
+
+
+
+
+
+
+
+Thomson                      Standards Track                    [Page 8]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+4.1.  Automatic Decryption
+
+   As a content coding, a "aes128gcm" content coding might be
+   automatically removed by a receiver in a way that is not obvious to
+   the ultimate consumer of a message.  Recipients that depend on
+   content-origin authentication using this mechanism MUST reject
+   messages that don't include the "aes128gcm" content coding.
+
+4.2.  Message Truncation
+
+   This content encoding is designed to permit the incremental
+   processing of large messages.  It also permits random access to
+   plaintext in a limited fashion.  The content encoding permits a
+   receiver to detect when a message is truncated.
+
+   A partially delivered message MUST NOT be processed as though the
+   entire message was successfully delivered.  For instance, a partially
+   delivered message cannot be cached as though it were complete.
+
+   An attacker might exploit willingness to process partial messages to
+   cause a receiver to remain in a specific intermediate state.
+   Implementations performing processing on partial messages need to
+   ensure that any intermediate processing states don't advantage an
+   attacker.
+
+4.3.  Key and Nonce Reuse
+
+   Encrypting different plaintext with the same content-encryption key
+   and nonce in AES-GCM is not safe [RFC5116].  The scheme defined here
+   uses a fixed progression of nonce values.  Thus, a new content-
+   encryption key is needed for every application of the content coding.
+   Since input-keying material can be reused, a unique "salt" parameter
+   is needed to ensure that a content-encryption key is not reused.
+
+   If a content-encryption key is reused -- that is, if input-keying
+   material and "salt" parameter are reused -- this could expose the
+   plaintext and the authentication key, nullifying the protection
+   offered by encryption.  Thus, if the same input-keying material is
+   reused, then the "salt" parameter MUST be unique each time.  This
+   ensures that the content-encryption key is not reused.  An
+   implementation SHOULD generate a random "salt" parameter for every
+   message.
+
+
+
+
+
+
+
+
+
+Thomson                      Standards Track                    [Page 9]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+4.4.  Data Encryption Limits
+
+   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 with the key derived
+   from the same input-keying material and salt MUST be less than 2^44.5
+   blocks of 16 octets [AEBounds].
+
+   If the record size is a multiple of 16 octets, this means that 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
+   18 octets, for which at most 74 terabytes of plaintext can be
+   encrypted, of which at least half is padding.
+
+4.5.  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.
+
+   Furthermore, any entity that is able to modify both the Content-
+   Encoding header field and the HTTP message body can replace the
+   contents.  Without the content-encryption key or the input-keying
+   material, modifications to, or replacement of, parts of a payload
+   body are not possible.
+
+4.6.  Leaking Information in Header Fields
+
+   Because only the payload body is encrypted, information exposed in
+   header fields is visible to anyone who can read the HTTP message.
+   This could expose side-channel information.
+
+   For example, the Content-Type header field can leak information about
+   the payload body.
+
+
+
+
+
+
+
+Thomson                      Standards Track                   [Page 10]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+   There are a number of strategies available to mitigate this threat,
+   depending upon the application's threat model and the users'
+   tolerance for leaked information:
+
+   1.  Determine that it is not an issue.  For example, if it is
+       expected that all content stored will be "application/json", or
+       another very common media type, exposing the Content-Type header
+       field could be an acceptable risk.
+
+   2.  If it is considered sensitive information and it is possible to
+       determine it through other means (e.g., out of band, using hints
+       in other representations, etc.), omit the relevant headers, and/
+       or normalize them.  In the case of Content-Type, this could be
+       accomplished by always sending Content-Type:
+       application/octet-stream (the most generic media type), or no
+       Content-Type at all.
+
+   3.  If it is considered sensitive information and it is not possible
+       to convey it elsewhere, encapsulate the HTTP message using the
+       application/http media type (see Section 8.3.2 of [RFC7230]),
+       encrypting that as the payload of the "outer" message.
+
+4.7.  Poisoning Storage
+
+   This mechanism only offers data-origin authentication; it does not
+   perform authentication or authorization of the message creator, which
+   could still need to be performed (e.g., by HTTP authentication
+   [RFC7235]).
+
+   This is especially relevant when an HTTP PUT request is accepted by a
+   server without decrypting the payload; if the request is
+   unauthenticated, it becomes possible for a third party to deny
+   service and/or poison the store.
+
+4.8.  Sizing and Timing Attacks
+
+   Applications using this mechanism need to be aware that the size of
+   encrypted messages, as well as their timing, HTTP methods, URIs and
+   so on, may leak sensitive information.  See, for example, [NETFLIX]
+   or [CLINIC].
+
+   This risk can be mitigated through the use of the padding that this
+   mechanism provides.  Alternatively, splitting up content into
+   segments and storing them separately might reduce exposure.  HTTP/2
+   [RFC7540] combined with TLS [RFC5246] might be used to hide the size
+   of individual messages.
+
+
+
+
+
+Thomson                      Standards Track                   [Page 11]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+   Developing a padding strategy is difficult.  A good padding strategy
+   can depend on context.  Common strategies include padding to a small
+   set of fixed lengths, padding to multiples of a value, or padding to
+   powers of 2.  Even a good strategy can still cause size information
+   to leak if processing activity of a recipient can be observed.  This
+   is especially true if the trailing records of a message contain only
+   padding.  Distributing non-padding data across records is recommended
+   to avoid leaking size information.
+
+5.  IANA Considerations
+
+5.1.  The "aes128gcm" HTTP Content Coding
+
+   This memo registers the "aes128gcm" HTTP content coding in the "HTTP
+   Content Coding Registry", as detailed in Section 2.
+
+   o  Name: aes128gcm
+
+   o  Description: AES-GCM encryption with a 128-bit content-encryption
+      key
+
+   o  Reference: this specification
+
+6.  References
+
+6.1.  Normative References
+
+   [FIPS180-4]
+              National Institute of Standards and Technology, "Secure
+              Hash Standard (SHS)", FIPS PUB 180-4,
+              DOI 10.6028/NIST.FIPS180-4, August 2015,
+              <http://nvlpubs.nist.gov/nistpubs/FIPS/
+              NIST.FIPS.180-4.pdf>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <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
+              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
+              <http://www.rfc-editor.org/info/rfc5116>.
+
+
+
+
+
+Thomson                      Standards Track                   [Page 12]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
+              Key Derivation Function (HKDF)", RFC 5869,
+              DOI 10.17487/RFC5869, May 2010,
+              <http://www.rfc-editor.org/info/rfc5869>.
+
+   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Message Syntax and Routing",
+              RFC 7230, DOI 10.17487/RFC7230, June 2014,
+              <http://www.rfc-editor.org/info/rfc7230>.
+
+   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
+              DOI 10.17487/RFC7231, June 2014,
+              <http://www.rfc-editor.org/info/rfc7231>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <http://www.rfc-editor.org/info/rfc8174>.
+
+6.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>.
+
+   [CLINIC]   Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know
+              Why You Went to the Clinic: Risks and Realization of HTTPS
+              Traffic Analysis", DOI 10.1007/978-3-319-08506-7_8, March
+              2014, <https://arxiv.org/abs/1403.0297>.
+
+   [NETFLIX]  Reed, A. and M. Kranch, "Identifying HTTPS-Protected
+              Netflix Videos in Real-Time", Proceedings of the Seventh
+              ACM on Conference on Data and Application Security and
+              Privacy CODASPY '17, DOI 10.1145/3029806.3029821, 2017.
+
+   [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.
+              Thayer, "OpenPGP Message Format", RFC 4880,
+              DOI 10.17487/RFC4880, November 2007,
+              <http://www.rfc-editor.org/info/rfc4880>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+
+
+Thomson                      Standards Track                   [Page 13]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, DOI 10.17487/RFC5652, September 2009,
+              <http://www.rfc-editor.org/info/rfc5652>.
+
+   [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
+              "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
+              RFC 7233, DOI 10.17487/RFC7233, June 2014,
+              <http://www.rfc-editor.org/info/rfc7233>.
+
+   [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Authentication", RFC 7235,
+              DOI 10.17487/RFC7235, June 2014,
+              <http://www.rfc-editor.org/info/rfc7235>.
+
+   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
+              RFC 7516, DOI 10.17487/RFC7516, May 2015,
+              <http://www.rfc-editor.org/info/rfc7516>.
+
+   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
+              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
+              DOI 10.17487/RFC7540, May 2015,
+              <http://www.rfc-editor.org/info/rfc7540>.
+
+   [XMLENC]   Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler,
+              "XML Encryption Syntax and Processing Version 1.1", World
+              Wide Web Consortium Recommendation
+              REC-xmlenc-core1-20130411, April 2013,
+              <http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson                      Standards Track                   [Page 14]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+Appendix A.  JWE Mapping
+
+   The "aes128gcm" content coding can be considered as a sequence of
+   JSON Web Encryption (JWE) [RFC7516] objects, each corresponding to a
+   single fixed-size record that includes trailing padding.  The
+   following transformations are applied to a JWE object that might be
+   expressed using the JWE Compact Serialization:
+
+   o  The JWE Protected Header is fixed to the value { "alg": "dir",
+      "enc": "A128GCM" }, describing direct encryption using AES-GCM
+      with a 128-bit content-encryption key.  This header is not
+      transmitted, it is instead implied by the value of the Content-
+      Encoding header field.
+
+   o  The JWE Encrypted Key is empty, as stipulated by the direct
+      encryption algorithm.
+
+   o  The JWE Initialization Vector ("iv") for each record is set to the
+      exclusive-or of the 96-bit record sequence number, starting at
+      zero, and a value derived from the input-keying material (see
+      Section 2.3).  This value is also not transmitted.
+
+   o  The final value is the concatenated header, JWE Ciphertext, and
+      JWE Authentication Tag, all expressed without base64url encoding.
+      The "." separator is omitted, since the length of these fields is
+      known.
+
+   Thus, the example in Section 3.1 can be rendered using the JWE
+   Compact Serialization as:
+
+   eyAiYWxnIjogImRpciIsICJlbmMiOiAiQTEyOEdDTSIgfQ..Bcs8gkIRKLI8GeI8.
+   -NAVub2qFgBEuQKRapoZuw.4jGQi9rcwQHU8P6XLxOGOA
+
+   Where the first line represents the fixed JWE Protected Header, an
+   empty JWE Encrypted Key, and the algorithmically determined JWE
+   Initialization Vector.  The second line contains the encoded body,
+   split into JWE Ciphertext and JWE Authentication Tag.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson                      Standards Track                   [Page 15]
+
+RFC 8188                 HTTP Encryption Coding                June 2017
+
+
+Acknowledgements
+
+   Mark Nottingham was an original author of this document.
+
+   The following people provided valuable input: Richard Barnes, David
+   Benjamin, Peter Beverloo, JR Conlin, Mike Jones, Stephen Farrell,
+   Adam Langley, James Manger, John Mattsson, Julian Reschke, Eric
+   Rescorla, Jim Schaad, and Magnus Westerlund.
+
+Author's Address
+
+   Martin Thomson
+   Mozilla
+
+   Email: martin.thomson@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson                      Standards Track                   [Page 16]
+