Mozilla

martin.thomson@gmail.com

A 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 (UA) via a push service.

| | | Provide Subscription | |-------------------------------------------->| | | | : : : | | Push Message | | Push Message |<---------------------| |<---------------------| | | | | ]]>

This document describes how messages sent using this protocol can be secured against inspection, modification and forgery 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. Multiple users of Web Push at the same user agent 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 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 when, and only when, they appear in all capitals, as shown here. This document uses the terminology from , primarily user agent, push service, and application server.

Encrypting a push message uses elliptic-curve Diffie-Hellman (ECDH) on the P-256 curve to establish a shared secret (see ) and a symmetric secret for authentication (see ). A user agent generates an ECDH key pair and authentication secret that it associates with each subscription it creates. The ECDH public key and the authentication secret are sent to the application server with other details of the push subscription. When sending a message, an application server generates an ECDH key pair and a random salt. The ECDH public key is encoded into the keyid parameter of the encrypted content coding header, the salt in the salt parameter of that same header (see Section 2.1 of ). The ECDH key pair can be discarded after encrypting the message. The content of the push message is encrypted or decrypted using a content encryption key and nonce that is derived using all of these inputs and the process described in .

The application using the subscription distributes the subscription public key and authentication secret to an authorized application server. This could be sent along with other subscription information that is provided by the user agent, such as the push subscription URI. An application MUST use an authenticated, confidentiality protected communications medium for this purpose. In addition to the reasons described in , this ensures that the authentication secret is not revealed to unauthorized entities, which would allow those entities to generate push messages that will be accepted by the user agent. Most applications that use push messaging have a pre-existing relationship with an application server that can be used for distribution of subscription data. An authenticated communication mechanism that provides adequate confidentiality and integrity protection, such as HTTPS , is sufficient.

Push message encryption happens in four phases: A shared secret is derived using elliptic-curve Diffie-Hellman (). The shared secret is then combined with the authentication secret to produce the input keying material used in (). A content encryption key and nonce are derived using the process in . Encryption or decryption follows according to . The key derivation process is summarized in . Restrictions on the use of the encrypted content coding are described in .

For each new subscription that the user agent generates for an application, it also generates a P-256 key pair for use in elliptic-curve Diffie-Hellman (ECDH) . When sending a push message, the application server also generates a new ECDH key pair on the same P-256 curve. The ECDH public key for the application server is included as the “keyid” parameter in the encrypted content coding header (see Section 2.1 of . An application server combines its ECDH private key with the public key provided by the user agent using the process described in ; on receipt of the push message, a user agent combines its private key with the public key provided by the application server in the keyid parameter in the same way. These operations produce the same value for the ECDH shared secret.

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 shown in . A user agent MUST generate and provide a hard to guess sequence of 16 octets that is used for authentication of push messages. This SHOULD be generated by a cryptographically strong random number generator .

The shared secret produced by ECDH is combined with the authentication secret using the Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF) . This produces the input keying material used by . The HKDF function uses SHA-256 hash algorithm with the following inputs: the authentication secret the shared secret derived using ECDH the concatenation of the ASCII-encoded string “WebPush: info” (this string is not NUL-terminated), a zero octet, and the user agent ECDH public key and the application server ECDH public key, both in the uncompressed point form defined in ; that is:

32 octets (i.e., the output is the length of the underlying SHA-256 HMAC function output)

This results in a the final content encryption key and nonce generation using the following sequence, which is shown here in pseudocode with HKDF expanded into separate discrete steps using HMAC with SHA-256:

-- For an application server: ecdh_secret = ECDH(as_private, ua_public) auth_secret = salt = random(16) -- For both: ## Use HKDF to combine the ECDH and authentication secrets # HKDF-Extract(salt=auth_secret, IKM=ecdh_secret) PRK_key = HMAC-SHA-256(auth_secret, ecdh_secret) # HKDF-Expand(PRK_key, key_info, L_key=32) key_info = "WebPush: info" || 0x00 || ua_public || as_public IKM = HMAC-SHA-256(PRK_key, key_info || 0x01) ## HKDF calculations from RFC 8188 # HKDF-Extract(salt, IKM) PRK = HMAC-SHA-256(salt, IKM) # HKDF-Expand(PRK, cek_info, L_cek=16) cek_info = "Content-Encoding: aes128gcm" || 0x00 CEK = HMAC-SHA-256(PRK, cek_info || 0x01)[0..15] # HKDF-Expand(PRK, nonce_info, L_nonce=12) nonce_info = "Content-Encoding: nonce" || 0x00 NONCE = HMAC-SHA-256(PRK, nonce_info || 0x01)[0..11] ]]>

Note that this omits the exclusive OR of the final nonce with the record sequence number, since push messages contain only a single record (see ) and the sequence number of the first record is zero.

An application server MUST encrypt a push message with a single record. This allows for a minimal receiver implementation that handles a single record. An application server MUST set the rs parameter in the aes128gcm content coding header to a size that is greater than the sum of the lengths of the plaintext, the padding delimiter (1 octet), any padding, and the authentication tag (16 octets). A push message MUST include the application server ECDH public key in the keyid parameter of the encrypted content coding header. The uncompressed point form defined in (that is, a 65 octet sequence that starts with a 0x04 octet) forms the entirety of the keyid. Note that this means that the keyid parameter will not be valid UTF-8 as recommended in . A push service is not required to support more than 4096 octets of payload body (see Section 7.2 of ). Absent header (86 octets), padding (minimum 1 octet), and expansion for AEAD_AES_128_GCM (16 octets), this equates to at most 3993 octets of plaintext. 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 aes128gcm. Multiple aes128gcm values are not permitted. A user agent is not required to support multiple records. A user agent MAY ignore the rs field. If a record size is unchecked, decryption will fail with high probability for all valid cases. The padding delimiter octet MUST be checked, values other than 0x02 MUST cause the message to be discarded.

The following example shows a push message being sent to a push service.

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 wrapping and URL-safe base64url encoding to meet presentation constraints. The keys used are shown below using the uncompressed form encoded using base64url.

Intermediate values for this example are included in .

[[RFC EDITOR: please remove this section before publication.]] This document makes no request of IANA.

The privacy and security considerations of all apply to the use of this mechanism. The security considerations of describe the limitations of the content encoding. In particular, no HTTP header fields are protected by the content encoding scheme. A user agent MUST consider HTTP header fields to have come from the push service. Though header fields might be necessary for processing an HTTP response correctly, they are not needed for correct operation of the protocol. 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 which 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. The user agent and application MUST verify that the public key they receive is on the P-256 curve. Failure to validate a public key can allow an attacker to extract a private key. The appropriate validation procedures are defined in Section 4.3.7 of and alternatively in Section 5.6.2.6 of . This process consists of three steps: Verify that Y is not the point at infinity (O), Verify that for Y = (x, y) both integers are in the correct interval, Ensure that (x, y) is a correct solution to the elliptic curve equation. For these curves, implementers do not need to verify membership in the correct subgroup. In the event that this encryption scheme would need to be replaced, a new content coding scheme could be defined. In order to manage progressive deployment of the new scheme, the user agent can expose information on the content coding schemes that it supports. The supportedContentEncodings parameter of the Push API is an example of how this might be done.

SECG National Institute of Standards and Technology (NIST) ANSI This document describes a simple protocol for the delivery of real- time events to user agents. This scheme uses HTTP/2 server push. This memo introduces a content coding for HTTP that allows message payloads to be encrypted. In 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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Security 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. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. The 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. This 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. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]

The intermediate values calculated for the example in are shown here. The base64url values in these examples include whitespace that can be removed. The following are inputs to the calculation: V2hlbiBJIGdyb3cgdXAsIEkgd2FudCB0byBiZSBhIHdhdGVybWVsb24 BP4z9KsN6nGRTbVYI_c7VJSPQTBtkgcy27mlmlMoZIIg Dll6e3vCYLocInmYWAmS6TlzAC8wEqKK6PBru3jl7A8 yfWPiYE-n46HLnH0KqZOF1fJJU3MYrct3AELtAQ-oRw BCVxsr7N_eNgVRqvHtD0zTZsEc6-VV-JvLexhqUzORcx aOzi6-AYWXvTBHm4bjyPjs7Vd8pZGH6SRpkNtoIAiw4 q1dXpw3UpT5VOmu_cf_v6ih07Aems3njxI-JWgLcM94 DGv6ra1nlYgDCS1FRnbzlw BTBZMqHH6r4Tts7J_aSIgg Note that knowledge of just one of the private keys is necessary. The application server randomly generates the salt value, whereas salt is input to the receiver. This produces the following intermediate values: kyrL1jIIOHEzg3sM2ZWRHDRB62YACZhhSlknJ672kSs Snr3JMxaHVDXHWJn5wdC52WjpCtd2EIEGBykDcZW32k V2ViUHVzaDogaW5mbwAEJXGyvs3942BVGq8e0PTNNmwR zr5VX4m8t7GGpTM5FzFo7OLr4BhZe9MEebhuPI-OztV3 ylkYfpJGmQ22ggCLDgT-M_SrDepxkU21WCP3O1SUj0Ew bZIHMtu5pZpTKGSCIA5Zent7wmC6HCJ5mFgJkuk5cwAv MBKiiujwa7t45ewP S4lYMb_L0FxCeq0WhDx813KgSYqU26kOyzWUdsXYyrg 09_eUZGrsvxChDCGRCdkLiDXrReGOEVeSCdCcPBSJSc Q29udGVudC1FbmNvZGluZzogYWVzMTI4Z2NtAA oIhVW04MRdy2XN9CiKLxTg Q29udGVudC1FbmNvZGluZzogbm9uY2UA 4h_95klXJ5E_qnoN The salt, record size of 4096, and application server public key produce an 86 octet header of DGv6ra1nlYgDCS1FRnbzlwAAEABBBP4z 9KsN6nGRTbVYI_c7VJSPQTBtkgcy27ml mlMoZIIgDll6e3vCYLocInmYWAmS6Tlz AC8wEqKK6PBru3jl7A8. The push message plaintext has the padding delimiter octet (0x02) appended to produce V2hlbiBJIGdyb3cgdXAsIEkgd2FudCB0 byBiZSBhIHdhdGVybWVsb24C. The plaintext is then encrypted with AES-GCM, which emits ciphertext of 8pfeW0KbunFT06SuDKoJH9Ql87S1QUrd irN6GcG7sFz1y1sqLgVi1VhjVkHsUoEs bI_0LpXMuGvnzQ. The header and cipher text are concatenated and produce the result shown in .