]> Mozilla

mt@lowentropy.net

Applications and Real-Time Web-Based Push Notifications spam transdimensional annoyance perfect forward secrecy This document defines how to use purely symmetric cryptography with Web Push. This document obsoletes RFC 8291. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web-Based Push Notifications Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Message Encryption for Web Push defines a hybrid encryption system that depends on elliptic curve cryptography. This system is known to be vulnerable to compromise in the event that a cryptographically-relevant quantum computer (CRQC) is created. The risk of this resulting in the compromise of Web Push encryption will be increasingly likely as time passes . This document defines a message encryption design that uses purely symmetric algorithms, relying on a pre-shared symmetric key. This relies on building a system for signaling updates to the pre-shared key. That system is not described in this document. This document obsoletes RFC 8291 . This document is one of a pair. Its companion, is an alternative to this approach. describes how to encode messages using Hybrid Public Key Encryption (HPKE).

Conventions and Definitions 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.

Using HPKE in Web Push Web Push provides a messaging capability that allows applications to send small messages to user agents via a push service. The push service enables efficient message delivery, even when user agents have constrained connectivity. Typical interactions for Web Push are shown in .

Web Push Overview | | | | | | Provide Subscription | |-------------------------------------------->| | | | ~~~~~~~~~~~~~~~~~~~~~~~ (Later) ~~~~~~~~~~~~~~~~~~~~~~~ | | | | | Push Message | | Push Message |<---------------------| |<---------------------| | | | | ]]>

Encryption of push messages ensures that the push service is unable to read or alter the messages it handles. Web Push uses a hybrid encryption mode that combines a key-encapsulation mechanism (KEM) and pre-shared key (PSK) with authenticated encryption with additional data (AEAD) encryption. This document describes how this can be performed using purely symmetric ciphers. The overall encryption design is composed from two parts:

1. A user agent key configuration, where the user agent provides the information necessary to construct a message it will accept. This is provided by the user agent to the application during the establishment of a Web Push subscription. Details of the format of this key configuration are provided in .
2. A message protection format, used to encode push messages. This format is defined in .

User Agent Key Configuration In order for an application server to send a push message using these keys, it requires knowledge of the PSK the user agent has chosen and the corresponding cipher. This information is formatted into a key configuration. shows the format of the key configuration, using the format described in .

Configuration Format

The format consists of one or more Symmetric Key items, each of which contains:

Key Identifier:

An 8 bit value that will be used in protected messages to identify the user agent's PSK and KEM secret key.

HPKE AEAD ID:

A 16 bit HPKE AEAD identifier as defined in or the HPKE AEAD IANA registry.

Key Length:

A 16 bit integer in network byte order that encodes the length, in bytes, of the Key field that follows.

Key:

A key for the identified AEAD, with a length determined by the If the encoded length of the key is not identical to the size of the key (Nk) in the definition of the AEAD, the entry MUST be discarded.

HPKE-Encrypted Push Message Format The format of push messages is illustrated in .

HPKE-Protected Push Message Format

Processes for the application server that sends messages are included in ; processes for the user agent that receives messages are included in .

Push Message Application Server Processing Applications encapsulate a push message, msg, using values from the key configuration:

• the key identifier from the configuration, key_id, with the corresponding AEAD identified by aead_id, and
• the pre-shared key from the configuration, key,

The application then constructs an encrypted push message, push_message, from the plaintext of the message, msg, as follows:

1. Generate a unique value for nonce. This value needs to be unique across all uses of the same pre-shared key.
2. Encrypt msg by invoking the Seal() method on the selected AEAD passing key and an empty associated data aad, yielding ciphertext ct.
3. Concatenate the values of key_id, nonce, and ct, yielding an encrypted push message push_message.

Ideally, senders maintain a counter and use that for nonces. However, coordinating a counter across multiple hosts can be challenging. For this reason, the value of nonce can be drawn at random, in which case the number of messages that can be protected with a single key MUST be significantly less than two to the power of half the number of bits in the nonce value. Setting a limit of 2^{Nn/2 - margin} messages, where margin is at least 20, provides a very low chance of collision. Note that nonce is of fixed-length, so there is no ambiguity in parsing this structure. In pseudocode, this procedure is as follows:

Push Message Receiver Processing An user agent decrypts a push message by reversing this process. To decapsulate the encrypted push message, push_message:

1. Parses push_message into key_id, nonce, and ct (indicated using the function parse() in pseudocode). The user agent is then able to find the pre-shared key, key. a. If key_id does not identify a key known to the user agent the user agent discards the message. b. Optionally, if nonce matches a value that has been used with this key, the user agent destroys the corresponding key and discards the message.
2. Decrypt ct by invoking the Open() method on the AEAD associated with the key, passing key, nonce, and an empty associated data, yielding msg` or an error on failure. If an error is returned, the user agent discards the message.

In pseudocode, this procedure is as follows:

Mandatory Algorithms All implementations of this specification MUST implement AES-128-GCM, identified as 0x0001 in .

Upgrading from RFC 8291 The encryption scheme in identifies itself through the use of the encrypted "aes128gcm" content coding . Though it is possible to use this message encryption system and the "aes128gcm" content coding at the same time, this is not generally necessary. A user agent can therefore use the absence of the encrypted content coding to indicate the use of this scheme. This document defines a media type for HPKE-protected push messages; see . This media type MAY be omitted if the "aes128gcm" content coding is not present. The use of post-quantum cryptography can increase the size of messages considerably. recommends that push services support ciphertext of 4096 bytes. This can reduce the available space for plaintext considerably. For example, using MLKEM768-X25519 means 1143 bytes of cryptographic overhead, compared to the 103-byte overhead in RFC 8291. Ideally, to allow for a smooth transition to PQ cryptography, push services would allow an additional 1kB for ciphertext. Unlike RFC 8291, no native padding facility is provided by this encryption format; see for details.

Security Considerations A Web Push user agent relies to some degree on two values remaining confidential to protect it from unwanted messages:

• the URL at which push messages are delivered, knowledge of which is necessary for messages to reach the user agent at all, and
• the pre-shared key that is used to authenticate the sender, which is the primary defense.

Knowledge of these values, along with the other parameters in the key configuration, allows an attacker to send any message it chooses to the user agent. Like the design in RFC 8291 (see ), this mechanism cannot obscure the presence, timing, and size of messages from the push service. Though communication with the push service is protected by TLS, without additional traffic analysis protection, network observers might also be able to observe these attributes of messages. Padding of the payload of messages can be used to obscure the precise size of the message, but no facility is provided in this document for padding messages. This differs from the RFC 8291 design, which was able to use the padding provided by the encoding. This document exercises the options described in for replacing the encryption scheme. Any replacement of this encryption scheme can use those same techniques.

Post-Compromise Security This message encryption scheme does not provide confidentiality of messages that are sent after a key becomes compromised. A key compromise leads to loss of confidentiality for all messages sent under the same key, in the past or future. Knowledge of the key also grants the ability to forge arbitrary new messages.

Nonce Collisions Protection of two different messages with an identical nonce leads to a key compromise in many AEAD functions. Applications MUST ensure that nonces used with the same key are unique. This document does not require that user agents track which nonces have been used, as that require significant state retention and computation. However, where a user agent detects nonce reuse it MUST discard the associated key. Messages that are merely replayed MUST NOT trigger this response. The user agent is encouraged to make all affected entities aware of the (potential) compromise of both previous and subsequent communications. This document does not require the use of a nonce-reuse resistant AEAD, but one might be defined based on something like .

AEAD Overuse Overuse of an AEAD key can give an attacker additional advantages that might lead to loss of confidentiality or the ability to forge messages. The guidance in MUST be followed with a target AEA advantage of 2^-40, assuming that all messages are 4096 bytes. Application servers MUST refuse to send messages beyond the corresponding limits; user agents MUST discard keys after receiving that many messages.

Handling Denial of Service A user agent that receives multiple unwanted messages, including messages that are discarded, might be the target of a denial of service attack. Such an attack might seek to drain batteries by activating the device radio or by creating messages that cannot be decrypted. A user agent can disable the associated subscription if they receive too many unwanted or invalid messages.

Media Type Security Push messages contain arbitrary content chosen by an application server. Though the format does not provide explicit signaling for the encapsulated media type, applications can include arbitrary data. How data is handled is determined by the application, which both sends and receives the data.

IANA Considerations This document registers the "application/webpush-message" content type to identify a push message that is protected with this scheme, as defined in .

Type name:

application

Subtype name:

webpush-message

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

"binary"

Security considerations:

see

Interoperability considerations:

N/A

Published specification:

this specification

Applications that use this media type:

This type identifies an encrypted web push message.

Fragment identifier considerations:

N/A

Additional information:

Magic number(s):

N/A

Deprecated alias names for this type:

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

Person and email address to contact for further information:

see Authors' Addresses section

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

see Authors' Addresses section

Change controller:

IETF

References Normative References Inria Rosenpass This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes a variant that authenticates possession of a pre-shared key. HPKE works for any combination of an asymmetric Key Encapsulation Mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. This document provides instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA-2. This document obsoletes RFC 9180. 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. 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. IBM Research Europe - Zurich Mozilla Cloudflare An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. Informative References This document describes a message encryption scheme for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an application server to a user agent. The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), and it details the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document sets out the problem statement for Interface to Network Security Functions (I2NSF) and outlines some companion use cases. This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated. This document is the product of the Crypto Forum Research Group.

Acknowledgments David Benjamin insisted that we attempt to use symmetric keys. This is because introducing a scheme that provides post-compromise security, such as the one in is somewhat more inefficient than this scheme.