draft-ietf-httpbis-encryption-encoding-08.txt		draft-ietf-httpbis-encryption-encoding-09.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 April 18, 2017
	Expires: September 3, 2017		Expires: October 20, 2017
	Encrypted Content-Encoding for HTTP		Encrypted Content-Encoding for HTTP
	draft-ietf-httpbis-encryption-encoding-08		draft-ietf-httpbis-encryption-encoding-09
	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 October 20, 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 24 ¶		skipping to change at page 2, line 24 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	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. Message Truncation . . . . . . . . . . . . . . . . . . . 9		4.1. Automatic Decryption . . . . . . . . . . . . . . . . . . 9
	4.2. Key and Nonce Reuse . . . . . . . . . . . . . . . . . . . 9		4.2. Message Truncation . . . . . . . . . . . . . . . . . . . 9
	4.3. Data Encryption Limits . . . . . . . . . . . . . . . . . 10		4.3. Key and Nonce Reuse . . . . . . . . . . . . . . . . . . . 9
	4.4. Content Integrity . . . . . . . . . . . . . . . . . . . . 10		4.4. Data Encryption Limits . . . . . . . . . . . . . . . . . 9
	4.5. Leaking Information in Header Fields . . . . . . . . . . 10		4.5. Content Integrity . . . . . . . . . . . . . . . . . . . . 10
	4.6. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 11		4.6. Leaking Information in Header Fields . . . . . . . . . . 10
	4.7. Sizing and Timing Attacks . . . . . . . . . . . . . . . . 11		4.7. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 11
			4.8. Sizing and Timing Attacks . . . . . . . . . . . . . . . . 11
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	5.1. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . 12		5.1. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . 12
	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 . . . . . . . . . . . . . . . . . 13
	Appendix A. JWE Mapping . . . . . . . . . . . . . . . . . . . . 14		Appendix A. JWE Mapping . . . . . . . . . . . . . . . . . . . . 14
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	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 5, line 47 ¶		skipping to change at page 5, line 47 ¶
	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 18 are invalid.		smaller than 18 are invalid.
	keyid: The "keyid" parameter can be used to identify the keying		idlen: The "idlen" parameter is an unsigned 8-bit integer that
	material that is used. Recipients that receive a message are		defines the length of the "keyid" parameter.
	expected to know how to retrieve keys; the "keyid" parameter might
	be input to that process. A "keyid" parameter SHOULD be a UTF-8
	[RFC3629] encoded string, particularly where the identifier might		keyid: The "keyid" parameter can be used to identify the keying
	need to appear in a textual form.		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 [RFC3629]
			encoded string, particularly where the identifier might need to be
			rendered 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 6, line 29 ¶		skipping to change at page 6, line 30 ¶
	be provided to recipients separately. The extract phase of HKDF		be provided to recipients separately. The extract phase of HKDF
	therefore produces a pseudorandom key (PRK) as follows:		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: aes128gcm" and a single zero octet:		"Content-Encoding: aes128gcm" and a single zero octet:
	cek_info = "Content-Encoding: aes128gcm" || 0x00		cek_info = "Content-Encoding: aes128gcm" || 0x00
	Note: Concatenation of octet sequences is represented by the "||"		Note(1): Concatenation of octet sequences is represented by the "||"
	operator.		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		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		(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)
	2.3. Nonce Derivation		2.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.
	skipping to change at page 7, line 21 ¶		skipping to change at page 7, line 21 ¶
	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.		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).
	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 8, line 24 ¶		skipping to change at page 8, line 15 ¶
	stream" to avoid exposing information about the content.		stream" to avoid exposing information about the content.
	Alternatively (and equivalently), the Content-Type header field can		Alternatively (and equivalently), the Content-Type header field can
	be omitted.		be omitted.
	Intermediate values for this example (all shown using base64url):		Intermediate values for this example (all shown using base64url):
	salt (from header) = I1BsxtFttlv3u_Oo94xnmw		salt (from header) = I1BsxtFttlv3u_Oo94xnmw
	PRK = zyeH5phsIsgUyd4oiSEIy35x-gIi4aM7y0hCF8mwn9g		PRK = zyeH5phsIsgUyd4oiSEIy35x-gIi4aM7y0hCF8mwn9g
	CEK = _wniytB-ofscZDh4tbSjHw		CEK = _wniytB-ofscZDh4tbSjHw
	NONCE = Bcs8gkIRKLI8GeI8		NONCE = Bcs8gkIRKLI8GeI8
	plaintext = SSBhbSB0aGUgd2FscnVzAg		unencrypted data = SSBhbSB0aGUgd2FscnVzAg
	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 25 octets each (that is, the "rs" field in the header		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		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		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		in the second. A key identifier of the UTF-8 encoded string "a1" is
	also included in the header.		also included in the header.
	skipping to change at page 9, line 12 ¶		skipping to change at page 9, line 5 ¶
	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 -
	can be difficult. For instance, implementations need to account for		can be difficult. For instance, implementations need to account for
	the potential for exposing keying material on side channels, such as		the potential for exposing keying material on side channels, such as
	might be exposed by the time it takes to perform a given operation.		might be exposed by the time it takes to perform a given operation.
	The requirements for a good implementation of cryptographic		The requirements for a good implementation of cryptographic
	algorithms can change over time.		algorithms can change over time.
	As a content coding, presence of the "aes128gcm" coding might be		4.1. Automatic Decryption
	transparent to a 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.1. Message Truncation		As a content coding, a "aes128gcm" content coding might be
			automatically removed by a receiver in 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		This content encoding is designed to permit the incremental
	processing of large messages. It also permits random access to		processing of large messages. It also permits random access to
	plaintext in a limited fashion. The content encoding permits a		plaintext in a limited fashion. The content encoding permits a
	receiver to detect when a message is truncated.		receiver to detect when a message is truncated.
	A partially delivered message MUST NOT be processed as though the		A partially delivered message MUST NOT be processed as though the
	entire message was successfully delivered. For instance, a partially		entire message was successfully delivered. For instance, a partially
	delivered message cannot be cached as though it were complete.		delivered message cannot be cached as though it were complete.
	An attacker might exploit willingness to process partial messages to		An attacker might exploit willingness to process partial messages to
	cause a receiver to remain in a specific intermediate state.		cause a receiver to remain in a specific intermediate state.
	Implementations performing processing on partial messages need to		Implementations performing processing on partial messages need to
	ensure that any intermediate processing states don't advantage an		ensure that any intermediate processing states don't advantage an
	attacker.		attacker.
	4.2. Key and Nonce Reuse		4.3. Key and Nonce Reuse
	Encrypting different plaintext with the same content encryption key		Encrypting different plaintext with the same content encryption key
	and nonce in AES-GCM is not safe [RFC5116]. The scheme defined here		and nonce in AES-GCM is not safe [RFC5116]. The scheme defined here
	uses a fixed progression of nonce values. Thus, a new content		uses a fixed progression of nonce values. Thus, a new content
	encryption key is needed for every application of the content coding.		encryption key is needed for every application of the content coding.
	Since input keying material can be reused, a unique "salt" parameter		Since input keying material can be reused, a unique "salt" parameter
	is needed to ensure a content encryption key is not reused.		is needed to ensure a content encryption key is not reused.
	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.
	achieve the same result.
	4.3. Data Encryption Limits		4.4. Data Encryption Limits
	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 with the key derived		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		from the same input keying material and salt MUST be less than 2^44.5
	blocks of 16 octets [AEBounds].		blocks of 16 octets [AEBounds].
	If the record size is a multiple of 16 octets, this means 398		If the record size is a multiple of 16 octets, this means 398
	terabytes can be encrypted safely, including padding and overhead.		terabytes can be encrypted safely, including padding and overhead.
	However, if the record size is not a multiple of 16 octets, the total		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		amount of data that can be safely encrypted is reduced because
	skipping to change at page 10, line 25 ¶		skipping to change at page 10, line 19 ¶
	blocks of 16 octets [AEBounds].		blocks of 16 octets [AEBounds].
	If the record size is a multiple of 16 octets, this means 398		If the record size is a multiple of 16 octets, this means 398
	terabytes can be encrypted safely, including padding and overhead.		terabytes can be encrypted safely, including padding and overhead.
	However, if the record size is not a multiple of 16 octets, the total		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		amount of data that can be safely encrypted is reduced because
	partial AES blocks are encrypted. The worst case is a record size of		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		18 octets, for which at most 74 terabytes of plaintext can be
	encrypted, of which at least half is padding.		encrypted, of which at least half is padding.
	4.4. Content Integrity		4.5. 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 Content-		Furthermore, any entity that is able to modify both the Content-
	Encoding header field and the HTTP message body can replace the		Encoding header field and the HTTP message body can replace the
	contents. Without the content encryption key or the input keying		contents. Without the content encryption key or the input keying
	material, modifications to or replacement of parts of a payload body		material, modifications to or replacement of parts of a payload body
	are not possible.		are not possible.
	4.5. Leaking Information in Header Fields		4.6. Leaking Information in Header Fields
	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 11, line 22 ¶		skipping to change at page 11, 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.
	4.6. Poisoning Storage		4.7. Poisoning Storage
	This mechanism only offers encryption of content; it does not perform		This mechanism only offers data origin authentication; it does not
	authentication or authorization, which still needs to be performed		perform authentication or authorization of the message creator, which
	(e.g., by HTTP authentication [RFC7235]).		could still need to be performed (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 without decrypting the payload; if the request is
	third party to deny service and/or poison the store.		unauthenticated, it becomes possible for a third party to deny
			service and/or poison the store.
	4.7. Sizing and Timing Attacks		4.8. 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. See for example [NETFLIX] or
			[CLINIC].
	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 them separately might reduce exposure. HTTP/2		segments and storing them 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.
	Developing a padding strategy is difficult. A good padding strategy		Developing a padding strategy is difficult. A good padding strategy
	can depend on context. Common strategies include padding to a small		can depend on context. Common strategies include padding to a small
	set of fixed lengths, padding to multiples of a value, or padding to		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		powers of 2. Even a good strategy can still cause size information
	to leak if processing activity of a recipient can be observed. This		to leak if processing activity of a recipient can be observed. This
	is especially true if the trailing records of a message contain only		is especially true if the trailing records of a message contain only
	padding. Distributing non-padding data is recommended to avoid		padding. Distributing non-padding data across records is recommended
	leaking size information.		to avoid leaking size information.
	5. IANA Considerations		5. IANA Considerations
	5.1. The "aes128gcm" HTTP Content Coding		5.1. The "aes128gcm" HTTP Content Coding
	This memo registers the "aes128gcm" HTTP content coding in the HTTP		This memo registers the "aes128gcm" HTTP content coding in the HTTP
	Content Codings Registry, as detailed in Section 2.		Content Codings Registry, as detailed in Section 2.
	o Name: aes128gcm		o Name: aes128gcm
	skipping to change at page 13, line 10 ¶		skipping to change at page 13, line 10 ¶
	[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>.
			[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", 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.		[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. 28 change blocks.
	51 lines changed or deleted		71 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/