WebPush Encryption using Symmetric Ciphers

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 25 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Message Encryption for Web Push [RFC8291] 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 [PQC-GUIDE].¶

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 [RFC8291].¶

This document is one of a pair. Its companion, [WEBPUSH-HPKE] is an alternative to this approach. [WEBPUSH-HPKE] describes how to encode messages using Hybrid Public Key Encryption (HPKE).¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Using HPKE in Web Push

Web Push [WEBPUSH] 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 Figure 1.¶

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 Section 4.¶

2. A message protection format, used to encode push messages. This format is defined in Section 5.¶

4. 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.¶

Figure 2 shows the format of the key configuration, using the format described in Section 1.3 of [QUIC].¶

Key Config {
  Symmetric Algorithms (32) ...,
}

Symmetric Key {
  Key Identifier (8),
  HPKE AEAD ID (16),
  Key Length (16),
  Key (Nk * 8),
}

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 Section 7.3 of [HPKE] 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.¶

5. HPKE-Encrypted Push Message Format

The format of push messages is illustrated in Figure 3.¶

HPKE-Protected Push Message {
  Key Identifier (8),
  Nonce (Nn),
  Encrypted Message Contents (..),
}

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

aead = find_aead(aead_id)
nonce = random_bits(aead.Nn)
ct = aead.Seal(key, nonce, "", msg)
push_message = concat(key_id, nonce, ct)

key_id, nonce, ct = parse(enc_request)
key, aead = find_key(key_id)
if not key: abort
if previously_seen(key_id, nonce):
  delete(key)
  abort
msg, error = aead.Open(key, "", nonce, ct)
if error: abort

6. Mandatory Algorithms

All implementations of this specification MUST implement AES-128-GCM, identified as 0x0001 in Section 7.3 of [HPKE].¶

7. Upgrading from RFC 8291

The encryption scheme in [RFC8291] identifies itself through the use of the encrypted "aes128gcm" content coding [RFC8188]. 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 Section 9. 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. Section 4 of [RFC8291] 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 Section 8 for details.¶

8. 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 Section 7 of [RFC8291]), 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 [RFC8188] encoding.¶

This document exercises the options described in [RFC8192] for replacing the encryption scheme. Any replacement of this encryption scheme can use those same techniques.¶

9. 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 Section 5.¶

Type name:

application¶

Subtype name:

webpush-message¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

"binary"¶

Security considerations:

see Section 8.5¶

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¶

10. References

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 [WEBPUSH-HPKE] is somewhat more inefficient than this scheme.¶

Author's Address