Message Encryption for Web PushMozillamartin.thomson@gmail.comA message encryption scheme is described for the Web Push protocol. This scheme
provides confidentiality and integrity for messages sent from an Application
Server to a User Agent.The Web Push protocol is an intermediated
protocol by necessity. Messages from an Application Server are delivered to a
User Agent via a Push Service.This document describes how messages sent using this protocol can be secured
against inspection, modification and falsification by a Push Service.Web Push messages are the payload of an HTTP message . These messages
are encrypted using an encrypted content encoding
. This document describes how this
content encoding is applied and describes a recommended key management scheme.For efficiency reasons, multiple users of Web Push often share a central agent
that aggregates push functionality. This agent can enforce the use of this
encryption scheme by applications that use push messaging. An agent that only
delivers messages that are properly encrypted strongly encourages the end-to-end
protection of messages.A web browser that implements the Web Push API can enforce the use of
encryption by forwarding only those messages that were properly encrypted.The words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” are used in this document.
It’s not shouting, when they are capitalized, they have the special meaning
described in .For each new subscription that the User Agent generates for an application, it
also generates an asymmetric key pair for use in Diffie-Hellman (DH) or
elliptic-curve Diffie-Hellman (ECDH) . The public key for this key pair
can then be distributed by the application to the Application Server along with
the URI of the subscription. The private key MUST remain secret.This key pair is used with the Diffie-Hellman key exchange as described in
Section 4.2 of .A User Agent MUST generate and provide a public key for the scheme described in
.The public key MUST be accompanied by a key identifier that can be used in the
“keyid” parameter to identify which key is in use. Key identifiers need only be
unique within the context of a subscription.As described in , use of Diffie-Hellman
for key agreement requires that the receiver provide clear information about its
chosen group and the format for the “dh” parameter with each potential sender.This document only describes a single ECDH group and point format, described in
. A specification that defines alternative groups or formats MUST
provide a means of indicating precisely which group and format is in use for
every public key that is provided.The application using the subscription distributes the key identifier and public
key along with other subscription information, such as the subscription URI and
expiration time.The communication medium by which an application distributes the key identifier
and public key MUST be confidentiality protected for the reasons described in
. Most applications that use push messaging have a
pre-existing relationship with an Application Server. Any existing
communication mechanism that is authenticated and provides confidentiality and
integrity, such as HTTPS , is sufficient.To ensure that push messages are correctly authenticated, a symmetric
authentication secret is added to the information generated by a User Agent.
The authentication secret is mixed into the key derivation process described in
.The authentication secret ensures that exposure or leakage of the DH public
key - which, as a public key, is not necessarily treated as a secret - does not
enable an adversary to generate valid push messages.A User Agent MUST generate and provide a hard to guess sequence of octets that
is used for authentication of push messages. This SHOULD be generated by a
cryptographically strong random number generator and be at least 16
octets long.An Application Server that has the public key, group and format information plus
the authentication secret can encrypt a message for the User Agent.The Application Server generates a new DH or ECDH key pair in the same group as
the value generated by the User Agent.From the newly generated key pair, the Application Server performs a DH or ECDH
computation with the public key provided by the User Agent to find the input
keying material for key derivation. The Application Server then generates 16
octets of salt that is unique to the message. A random salt is
acceptable.Web push uses the authentication secret defined in Section 4.3 of
. This authentication secret (see
) is generated by the user agent and shared with the application server.The Application Server then encrypts the payload. Header fields are populated
with base64url encoded values:the salt is added to the salt parameter of the Encryption header field; andthe public key for its DH or ECDH key pair is placed in the dh parameter of
the Crypto-Key header field.An application server MUST encrypt a push message with a single record. This
allows for a minimal receiver implementation that handles a single record. If
the message is 4096 octets or longer, the rs parameter MUST be set to a value
that is longer than the encrypted push message length.Note that a push service is not required to support more than 4096 octets of
payload body, which equates to 4077 octets of cleartext, so the rs parameter
can be omitted for messages that fit within this limit.An application server MUST NOT use other content encodings for push messages.
In particular, content encodings that compress could result in leaking of push
message contents. The Content-Encoding header field therefore has exactly one
value, which is aesgcm128. Multiple aesgcm128 values are not permitted.An application server MUST include exactly one entry in the Encryption field,
and at most one entry having a dh parameter in the Crypto-Key field. This
allows the keyid parameter to be omitted from both header fields.An application server MUST NOT include an aesgcm128 parameter in the
Encryption header field.A User Agent decrypts messages are decrypted as described in
. The authentication secret described in
is used in key derivation.Note that the value of the “keyid” parameter is used to identify the correct
share, if there are multiple values for the Crypto-Key header field.A receiver is not required to support multiple records. Such a receiver MUST
check that the record size is large enough to contain the entire payload body in
a single record. The rs parameter MUST NOT be exactly equal to the length of
the payload body minus the length of the authentication tag (16 octets); that
length indicates that the message has been truncated.User Agents MUST expose an elliptic curve Diffie-Hellman share on the P-256
curve .Public keys, such as are encoded into the “dh” parameter, MUST be in the form of
an uncompressed point as described in (that is, a 65 octet sequence that
starts with a 0x04 octet).The label for this curve is the string “P-256” encoded in ASCII (that is, the
octet sequence 0x50, 0x2d, 0x32, 0x35, 0x36).This document has no IANA actions.The security considerations of describe
the limitations of the content encoding. In particular, any HTTP header fields
are not protected by the content encoding scheme. A User Agent MUST consider
HTTP header fields to have come from the Push Service. An application on the
User Agent that uses information from header fields to alter their processing of
a push message is exposed to a risk of attack by the Push Service.The timing and length of communication cannot be hidden from the Push Service.
While an outside observer might see individual messages intermixed with each
other, the Push Service will see what Application Server is talking to which
User Agent, and the subscription that is used. Additionally, the length of
messages could be revealed unless the padding provided by the content encoding
scheme is used to obscure length.Generic Event Delivery Using HTTP PushA simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push.Encrypted Content-Encoding for HTTPThis memo introduces a content-coding for HTTP that allows message payloads to be encrypted. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ . Working Group information can be found at http://httpwg.github.io/ ; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/encryption .Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Randomness Requirements for SecuritySecurity systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.New Directions in CryptographyElliptic Curve CryptographySECGDigital Signature Standard (DSS)National Institute of Standards and Technology (NIST)Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)ANSIHTTP Over TLSThis memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.JSON Web Signature (JWS)JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingThe Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.Web Push API