idnits 2.17.1
draft-thomson-webpush-encryption-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (July 2, 2015) is 3219 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Possible downref: Non-RFC (?) normative reference: ref. 'DH'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ECDH'
-- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186'
== Outdated reference: A later version (-02) exists of
draft-thomson-http-encryption-01
-- Obsolete informational reference (is this intentional?): RFC 2818
(Obsoleted by RFC 9110)
-- Obsolete informational reference (is this intentional?): RFC 7230
(Obsoleted by RFC 9110, RFC 9112)
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M. Thomson
3 Internet-Draft Mozilla
4 Intended status: Standards Track July 2, 2015
5 Expires: January 3, 2016
7 Message Encryption for Web Push
8 draft-thomson-webpush-encryption-01
10 Abstract
12 A message encryption scheme is described for the Web Push protocol.
13 This scheme provides confidentiality and integrity for messages sent
14 from an Application Server to a User Agent.
16 Status of This Memo
18 This Internet-Draft is submitted in full conformance with the
19 provisions of BCP 78 and BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF). Note that other groups may also distribute
23 working documents as Internet-Drafts. The list of current Internet-
24 Drafts is at http://datatracker.ietf.org/drafts/current/.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 This Internet-Draft will expire on January 3, 2016.
33 Copyright Notice
35 Copyright (c) 2015 IETF Trust and the persons identified as the
36 document authors. All rights reserved.
38 This document is subject to BCP 78 and the IETF Trust's Legal
39 Provisions Relating to IETF Documents
40 (http://trustee.ietf.org/license-info) in effect on the date of
41 publication of this document. Please review these documents
42 carefully, as they describe your rights and restrictions with respect
43 to this document. Code Components extracted from this document must
44 include Simplified BSD License text as described in Section 4.e of
45 the Trust Legal Provisions and are provided without warranty as
46 described in the Simplified BSD License.
48 Table of Contents
50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
51 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
52 2. Key Generation and Agreement . . . . . . . . . . . . . . . . 3
53 2.1. Diffie-Hellman Group Information . . . . . . . . . . . . 3
54 2.2. Key Distribution . . . . . . . . . . . . . . . . . . . . 4
55 3. Message Encryption . . . . . . . . . . . . . . . . . . . . . 4
56 4. Message Decryption . . . . . . . . . . . . . . . . . . . . . 5
57 5. Mandatory Group and Public Key Format . . . . . . . . . . . . 5
58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
61 8.1. Normative References . . . . . . . . . . . . . . . . . . 6
62 8.2. Informative References . . . . . . . . . . . . . . . . . 6
63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
65 1. Introduction
67 The Web Push protocol [I-D.thomson-webpush-protocol] is an
68 intermediated protocol by necessity. Messages from an Application
69 Server are delivered to a User Agent via a Push Service.
71 +-------+ +--------------+ +-------------+
72 | UA | | Push Service | | Application |
73 +-------+ +--------------+ +-------------+
74 | | |
75 | Setup | |
76 |<====================>| |
77 | Provide Subscription |
78 |-------------------------------------------->|
79 | | |
80 : : :
81 | | Push Message |
82 | Push Message |<---------------------|
83 |<---------------------| |
84 | | |
86 This document describes how messages sent using this protocol can be
87 secured against inspection or modification by a Push Service.
89 Web Push messages are the payload of an HTTP message [RFC7230].
90 These messages are encrypted using an encrypted content encoding
91 [I-D.thomson-http-encryption]. This document describes how this
92 content encoding is applied and describes a recommended key
93 management scheme.
95 For efficiency reasons, multiple users of Web Push often share a
96 central agent that aggregates push functionality. This agent can
97 enforce the use of this encryption scheme by applications that use
98 push messaging. An agent that only delivers messages that are
99 properly encrypted strongly encourages the end-to-end protection of
100 messages.
102 A web browser that implements the Web Push API [API] can enforce the
103 use of encryption by forwarding only those messages that were
104 properly encrypted.
106 1.1. Notational Conventions
108 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
109 document. It's not shouting, when they are capitalized, they have
110 the special meaning described in [RFC2119].
112 2. Key Generation and Agreement
114 For each new subscription that the User Agent generates for an
115 application, it also generates an asymmetric key pair for use in
116 Diffie-Hellman (DH) [DH] or elliptic-curve Diffie-Hellman (ECDH)
117 [ECDH]. The public key for this key pair can then be distributed by
118 the application to the Application Server along with the URI of the
119 subscription. The private key MUST remain secret.
121 This key pair is used with the Diffie-Hellman key exchange as
122 described in Section 4.2 of [I-D.thomson-http-encryption].
124 A User Agent MUST generate and provide a public key for the scheme
125 described in Section 5.
127 The public key MUST be accompanied by a key identifier that can be
128 used in the "keyid" parameter to identify which key is in use. Key
129 identifiers need only be unique within the context of a subscription.
131 2.1. Diffie-Hellman Group Information
133 As described in [I-D.thomson-http-encryption], use of Diffie-Hellman
134 for key agreement requires that the receiver provide clear
135 information about it's chosen group and the format for the "dh"
136 parameter with each potential sender.
138 This document only describes a single ECDH group and point format,
139 described in Section 5. A specification that defines alternative
140 groups or formats MUST provide a means of indicating precisely which
141 group and format is in use for every public key that is provided.
143 2.2. Key Distribution
145 The application using the subscription distributes the key identifier
146 and public key along with other subscription information, such as the
147 subscription URI and expiration time.
149 The communication medium by which an application distributes the key
150 identifier and public key MUST be confidentiality protected for the
151 reasons described in [I-D.thomson-webpush-protocol]. Most
152 applications that use push messaging have a pre-existing relationship
153 with an Application Server. Any existing communication mechanism
154 that is authenticated and provides confidentiality and integrity,
155 such as HTTPS [RFC2818], is sufficient.
157 3. Message Encryption
159 An Application Server that has the key identifier, public key, group
160 and format information can encrypt a message for the User Agent.
162 The Application Server generates a new DH or ECDH key pair in the
163 same group as the value generated by the User Agent.
165 From the newly generated key pair, the Application Server performs a
166 DH or ECDH computation with the public key provided by the User Agent
167 to find the shared secret. The Application Server then generates 16
168 octets of salt that is unique to the message. A random [RFC4086]
169 salt is acceptable. These values are used to calculate the content
170 encryption key as defined in Section 3.2 of
171 [I-D.thomson-http-encryption].
173 The Application Server then encrypts the payload. Header fields are
174 populated with URL-safe base-64 encoded [RFC4648] values:
176 o the "keyid" from the User Agent is added to both the Encryption-
177 Key and Encryption header fields;
179 o the salt is added to the "salt" parameter of the Encryption header
180 field; and
182 o the public key for its DH or ECDH key pair is placed in the "dh"
183 parameter of the Encryption-Key header field.
185 An application server MUST encrypt a push message with a single
186 record. This allows for a minimal receiver implementation that
187 handles a single record. If the message is 4096 octets long, or
188 longer, this means that the "rs" parameter MUST be set to a value
189 that is longer than the encrypted push message length.
191 Note that a push service is not required to support more than 4096
192 octets of payload body, which equates to 4080 octets of cleartext, so
193 the "rs" parameter can be omitted for messages that fit within this
194 limit.
196 4. Message Decryption
198 A User Agent decrypts messages are decrypted as described in
199 [I-D.thomson-http-encryption]. The value of the "keyid" parameter is
200 used to identify the correct key pair, if there is more than one
201 possible value for the corresponding subscription.
203 A receiver is not required to support multiple records. Such a
204 receiver MUST check that the record size is large enough to contain
205 the entire payload body in a single record. The "rs" parameter MUST
206 NOT be exactly equal to the length of the payload body minus the
207 length of the authentication tag (16 octets); that length indicates
208 that the message has been truncated.
210 5. Mandatory Group and Public Key Format
212 User Agents that enforce encryption MUST expose an elliptic curve
213 Diffie-Hellman share on the P-256 curve [FIPS186]. Public keys, such
214 as are encoded into the "dh" parameter, MUST be in the form of an
215 uncompressed point as described in [X.692].
217 6. IANA Considerations
219 This document has no IANA actions.
221 7. Security Considerations
223 The security considerations of [I-D.thomson-http-encryption] describe
224 the limitations of the content encoding. In particular, any HTTP
225 header fields are not protected by the content encoding scheme. A
226 User Agent MUST consider HTTP header fields to have come from the
227 Push Service. An application on the User Agent that uses information
228 from header fields to alter their processing of a push message is
229 exposed to a risk of attack by the Push Service.
231 The timing and length of communication cannot be hidden from the Push
232 Service. While an outside observer might see individual messages
233 intermixed with each other, the Push Service will see what
234 Application Server is talking to which User Agent, and the
235 subscription they are talking about. Additionally, the length of
236 messages could be revealed unless the padding provided by the content
237 encoding scheme is used to obscure length.
239 8. References
241 8.1. Normative References
243 [DH] Diffie, W. and M. Hellman, "New Directions in
244 Cryptography", IEEE Transactions on Information Theory,
245 V.IT-22 n.6 , June 1977.
247 [ECDH] SECG, "Elliptic Curve Cryptography", SEC 1 , 2000,
248 .
250 [FIPS186] National Institute of Standards and Technology (NIST),
251 "Digital Signature Standard (DSS)", NIST PUB 186-4 , July
252 2013.
254 [I-D.thomson-http-encryption]
255 Thomson, M., "Encrypted Content-Encoding for HTTP", draft-
256 thomson-http-encryption-01 (work in progress), July 2015.
258 [I-D.thomson-webpush-protocol]
259 Thomson, M., Damaggio, E., and B. Raymor, "Generic Event
260 Delivery Using HTTP Push", draft-thomson-webpush-
261 protocol-00 (work in progress), April 2015.
263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
264 Requirement Levels", BCP 14, RFC 2119, March 1997.
266 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
267 Requirements for Security", BCP 106, RFC 4086, June 2005.
269 [X.692] ANSI, "Public Key Cryptography For The Financial Services
270 Industry: The Elliptic Curve Digital Signature Algorithm
271 (ECDSA)", ANSI X9.62 , 1998.
273 8.2. Informative References
275 [API] Sullivan, B., Fullea, E., and M. van Ouwerkerk, "Web Push
276 API", 2015, .
278 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
280 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
281 Encodings", RFC 4648, October 2006.
283 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
284 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
285 2014.
287 Author's Address
289 Martin Thomson
290 Mozilla
292 Email: martin.thomson@gmail.com