< draft-ietf-webpush-encryption-07.txt		draft-ietf-webpush-encryption-08.txt >
	Network Working Group M. Thomson		Network Working Group M. Thomson
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track December 21, 2016		Intended status: Standards Track February 14, 2017
	Expires: June 24, 2017		Expires: August 18, 2017
	Message Encryption for Web Push		Message Encryption for Web Push
	draft-ietf-webpush-encryption-07		draft-ietf-webpush-encryption-08
	Abstract		Abstract
	A message encryption scheme is described for the Web Push protocol.		A message encryption scheme is described for the Web Push protocol.
	This scheme provides confidentiality and integrity for messages sent		This scheme provides confidentiality and integrity for messages sent
	from an Application Server to a User Agent.		from an Application Server to a User Agent.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	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 August 18, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 6, line 38 ¶		skipping to change at page 6, line 38 ¶
	record sequence number, since push messages contain only a single		record sequence number, since push messages contain only a single
	record (see Section 4) and the sequence number of the first record is		record (see Section 4) and the sequence number of the first record is
	zero.		zero.
	4. Restrictions on Use of "aes128gcm" Content Coding		4. Restrictions on Use of "aes128gcm" Content Coding
	An Application Server MUST encrypt a push message with a single		An Application Server MUST encrypt a push message with a single
	record. This allows for a minimal receiver implementation that		record. This allows for a minimal receiver implementation that
	handles a single record. An application server MUST set the "rs"		handles a single record. An application server MUST set the "rs"
	parameter in the "aes128gcm" content coding header to a size that is		parameter in the "aes128gcm" content coding header to a size that is
	greater than the length of the plaintext, plus any padding (which is		greater than the some of the length of the plaintext, the padding
	at least 2 octets).		delimiter (1 octet), any padding, and the authentication tag (16
			octets).
	A push message MUST include the application server ECDH public key in		A push message MUST include the application server ECDH public key in
	the "keyid" parameter of the encrypted content coding header. The		the "keyid" parameter of the encrypted content coding header. The
	uncompressed point form defined in [X9.62] (that is, a 65 octet		uncompressed point form defined in [X9.62] (that is, a 65 octet
	sequence that starts with a 0x04 octet) forms the entirety of the		sequence that starts with a 0x04 octet) forms the entirety of the
	"keyid".		"keyid".
	A push service is not required to support more than 4096 octets of		A push service is not required to support more than 4096 octets of
	payload body (see Section 7.2 of [I-D.ietf-webpush-protocol]).		payload body (see Section 7.2 of [I-D.ietf-webpush-protocol]).
	Absent header (86 octets), padding (minimum 2 octets), and expansion		Absent header (86 octets), padding (minimum 2 octets), and expansion
	skipping to change at page 7, line 13 ¶		skipping to change at page 7, line 15 ¶
	of plaintext.		of plaintext.
	An Application Server MUST NOT use other content encodings for push		An Application Server MUST NOT use other content encodings for push
	messages. In particular, content encodings that compress could		messages. In particular, content encodings that compress could
	result in leaking of push message contents. The Content-Encoding		result in leaking of push message contents. The Content-Encoding
	header field therefore has exactly one value, which is "aes128gcm".		header field therefore has exactly one value, which is "aes128gcm".
	Multiple "aes128gcm" values are not permitted.		Multiple "aes128gcm" values are not permitted.
	A User Agent is not required to support multiple records. A User		A User Agent is not required to support multiple records. A User
	Agent MAY ignore the "rs" field. If a record size is unchecked,		Agent MAY ignore the "rs" field. If a record size is unchecked,
	decryption will fail with high probability for all valid cases.		decryption will fail with high probability for all valid cases. The
	However, decryption will succeed if the push message contains a		padding delimiter octet MUST be checked, values other than 0x02 MUST
	single record from a longer truncated message. Given that an		cause the message to be discarded.
	Application Server is prohibited from generating such a message, this
	is not considered a serious risk.
	5. Push Message Encryption Example		5. Push Message Encryption Example
	The following example shows a push message being sent to a push		The following example shows a push message being sent to a push
	service.		service.
	POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1		POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
	Host: push.example.net		Host: push.example.net
	TTL: 10		TTL: 10
	Content-Length: 145		Content-Length: 145
	Content-Encoding: aes128gcm		Content-Encoding: aes128gcm
	DGv6ra1nlYgDCS1FRnbzlwAAEABBBP4z9KsN6nGRTbVYI_c7VJSPQTBtkgcy27ml		DGv6ra1nlYgDCS1FRnbzlwAAEABBBP4z9KsN6nGRTbVYI_c7VJSPQTBtkgcy27ml
	mlMoZIIgDll6e3vCYLocInmYWAmS6TlzAC8wEqKK6PBru3jl7A-l_-xdB7y6XwHb		mlMoZIIgDll6e3vCYLocInmYWAmS6TlzAC8wEqKK6PBru3jl7A_yl95bQpu6cVPT
	oeEO-lBPsSXN9axUBN3F53dcg7-wSrTIXywmEmPfWg78ZJX4LQzTaEaZMuHcWDuK		pK4Mqgkf1CXztLVBSt2Ks3oZwbuwXPXLWyouBWLVWGNWQexSgSxsj_Qulcy4a-fN
	6g
	This example shows the ASCII encoded string, "When I grow up, I want		This example shows the ASCII encoded string, "When I grow up, I want
	to be a watermelon". The content body is shown here with line		to be a watermelon". The content body is shown here with line
	wrapping and URL-safe base64url encoding to meet presentation		wrapping and URL-safe base64url encoding to meet presentation
	constraints.		constraints.
	The keys used are shown below using the uncompressed form [X9.62]		The keys used are shown below using the uncompressed form [X9.62]
	encoded using base64url.		encoded using base64url.
	Authentication Secret: BTBZMqHH6r4Tts7J_aSIgg		Authentication Secret: BTBZMqHH6r4Tts7J_aSIgg
	skipping to change at page 8, line 47 ¶		skipping to change at page 8, line 47 ¶
	Secure Hash Standard", March 2012,		Secure Hash Standard", March 2012,
	<http://nvlpubs.nist.gov/nistpubs/FIPS/		<http://nvlpubs.nist.gov/nistpubs/FIPS/
	NIST.FIPS.180-4.pdf>.		NIST.FIPS.180-4.pdf>.
	[FIPS186] National Institute of Standards and Technology (NIST),		[FIPS186] National Institute of Standards and Technology (NIST),
	"Digital Signature Standard (DSS)", NIST PUB 186-4 , July		"Digital Signature Standard (DSS)", NIST PUB 186-4 , July
	2013.		2013.
	[I-D.ietf-httpbis-encryption-encoding]		[I-D.ietf-httpbis-encryption-encoding]
	Thomson, M., "Encrypted Content-Encoding for HTTP", draft-		Thomson, M., "Encrypted Content-Encoding for HTTP", draft-
	ietf-httpbis-encryption-encoding-04 (work in progress),		ietf-httpbis-encryption-encoding-02 (work in progress),
	October 2016.		June 2016.
	[I-D.ietf-webpush-protocol]		[I-D.ietf-webpush-protocol]
	Thomson, M., Damaggio, E., and B. Raymor, "Generic Event		Thomson, M., Damaggio, E., and B. Raymor, "Generic Event
	Delivery Using HTTP Push", draft-ietf-webpush-protocol-12		Delivery Using HTTP Push", draft-ietf-webpush-protocol-08
	(work in progress), October 2016.		(work in progress), July 2016.
	[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>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<http://www.rfc-editor.org/info/rfc4086>.		<http://www.rfc-editor.org/info/rfc4086>.
	skipping to change at page 10, line 52 ¶		skipping to change at page 10, line 52 ¶
	Q29udGVudC1FbmNvZGluZzogYWVzMTI4Z2NtAA		Q29udGVudC1FbmNvZGluZzogYWVzMTI4Z2NtAA
	Content encryption key (CEK): oIhVW04MRdy2XN9CiKLxTg		Content encryption key (CEK): oIhVW04MRdy2XN9CiKLxTg
	Info for content encryption nonce derivation (nonce_info):		Info for content encryption nonce derivation (nonce_info):
	Q29udGVudC1FbmNvZGluZzogbm9uY2UA		Q29udGVudC1FbmNvZGluZzogbm9uY2UA
	Nonce (NONCE): 4h_95klXJ5E_qnoN		Nonce (NONCE): 4h_95klXJ5E_qnoN
	The salt, record size of 4096, and application server public key		The salt, record size of 4096, and application server public key
	produce an 86 octet header of		produce an 86 octet header of DGv6ra1nlYgDCS1FRnbzlwAAEABBBP4z
	DGv6ra1nlYgDCS1FRnbzlwAAEABBBP4z9KsN6nGR		9KsN6nGRTbVYI_c7VJSPQTBtkgcy27ml mlMoZIIgDll6e3vCYLocInmYWAmS6Tlz
	TbVYI_c7VJSPQTBtkgcy27mlmlMoZIIgDll6e3vC		AC8wEqKK6PBru3jl7A8.
	YLocInmYWAmS6TlzAC8wEqKK6PBru3jl7A8.
	The push message plaintext is padded to produce		The push message plaintext has the padding delimiter octet (0x02)
	AABXaGVuIEkgZ3JvdyB1cCwgSSB3YW50IHRvIGJl IGEgd2F0ZXJtZWxvbg. The		appended to produce V2hlbiBJIGdyb3cgdXAsIEkgd2FudCB0
	plaintext is then encrypted with AES-GCM, which emits ciphertext of		byBiZSBhIHdhdGVybWVsb24C. The plaintext is then encrypted with AES-
	pf_sXQe8ul8B26HhDvpQT7ElzfWsVATdxed3XIO_ sEq0yF8sJhJj31oO_GSV-		GCM, which emits ciphertext of 8pfeW0KbunFT06SuDKoJH9Ql87S1QUrd
	C0M02hGmTLh3Fg7iuo.		irN6GcG7sFz1y1sqLgVi1VhjVkHsUoEs bI_0LpXMuGvnzQ.
	The header and cipher text are concatenated and produce the result		The header and cipher text are concatenated and produce the result
	shown in the example.		shown in Section 5.
	Author's Address		Author's Address
	Martin Thomson		Martin Thomson
	Mozilla		Mozilla
	Email: martin.thomson@gmail.com		Email: martin.thomson@gmail.com
End of changes. 12 change blocks.
	29 lines changed or deleted		26 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/