WebPush Encryption using HPKE
draft-thomson-webpush-hpke-00

Web-Based Push Notifications                                  M. Thomson
Internet-Draft                                                   Mozilla
Obsoletes: 8291 (if approved)                               24 July 2026
Intended status: Standards Track                                        
Expires: 25 January 2027

                     WebPush Encryption using HPKE
                     draft-thomson-webpush-hpke-00

Abstract

   This document defines how to use Hybrid Public Key Encryption (HPKE)
   with Web Push.

   This document obsoletes RFC 8291.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://martinthomson.github.io/webpush-hpke/draft-thomson-webpush-
   hpke.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-thomson-webpush-hpke/.

   Discussion of this document takes place on the Web-Based Push
   Notifications Working Group mailing list (mailto:webpush@ietf.org),
   which is archived at https://mailarchive.ietf.org/arch/browse/
   webpush/.  Subscribe at https://www.ietf.org/mailman/listinfo/
   webpush/.

   Source for this draft and an issue tracker can be found at
   https://github.com/martinthomson/webpush-hpke.

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/.

Thomson                  Expires 25 January 2027                [Page 1]
Internet-Draft        WebPush Encryption using HPKE            July 2026

   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Using HPKE in Web Push  . . . . . . . . . . . . . . . . . . .   3
   4.  User Agent Key Configuration  . . . . . . . . . . . . . . . .   4
   5.  HPKE-Encrypted Push Message Format  . . . . . . . . . . . . .   6
     5.1.  Push Message Application Server Processing  . . . . . . .   7
     5.2.  Push Message Receiver Processing  . . . . . . . . . . . .   8
   6.  Mandatory Algorithms  . . . . . . . . . . . . . . . . . . . .   9
   7.  Upgrading from RFC 8291 . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     8.1.  Handling Denial of Service  . . . . . . . . . . . . . . .  10
     8.2.  Multi-Target Ciphertexts in RFC 8291  . . . . . . . . . .  10
     8.3.  Media Type Security . . . . . . . . . . . . . . . . . . .  11
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

Thomson                  Expires 25 January 2027                [Page 2]
Internet-Draft        WebPush Encryption using HPKE            July 2026

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 can integrate
   a post-quantum KEM.  This design is a generic use of Hybrid Public
   Key Encryption (HPKE) [HPKE] that can use any defined set of
   algorithms.

   At the same time, the use of HPKE addresses a minor, but
   inconsequential, vulnerability in the design of [RFC8291] that would
   allow an application to construct a single ciphertext that two
   parties would successfully authenticate and decrypt to different
   plaintexts.  This attack is described in Section 8.2.

   This document obsoletes RFC 8291 [RFC8291].

   This document is one of a pair.  Its companion, [WEBPUSH-SYM] is an
   alternative to this approach.  [WEBPUSH-SYM] describes how to encode
   messages using symmetric cryptography.

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.

Thomson                  Expires 25 January 2027                [Page 3]
Internet-Draft        WebPush Encryption using HPKE            July 2026

       +-------+           +--------------+       +-------------+
       |  UA   |           | Push Service |       | Application |
       +-------+           +--------------+       +-------------+
           |                      |                      |
           |        Setup         |                      |
           |<====================>|                      |
           |                      |                      |
           |           Provide Subscription              |
           |-------------------------------------------->|
           |                      |                      |
       ~~~~~~~~~~~~~~~~~~~~~~~ (Later) ~~~~~~~~~~~~~~~~~~~~~~~
           |                      |                      |
           |                      |     Push Message     |
           |    Push Message      |<---------------------|
           |<---------------------|                      |
           |                      |                      |

                        Figure 1: Web Push Overview

   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 provided by [HPKE].

   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 HPKE,
   it requires knowledge of:

   *  the HPKE algorithms that the user agent accepts,

   *  the PSK the user agent has chosen, and

   *  the KEM public key (or keys) the user agent holds secret keys for.

Thomson                  Expires 25 January 2027                [Page 4]
Internet-Draft        WebPush Encryption using HPKE            July 2026

   This information is formatted into a key configuration, similar in
   shape to that used in the Encrypted Client Hello (ECH) HpkeKeyConfig
   (Section 4 of [ECH]) or the Oblivious HTTP key configuration
   (Section 3 of [OHTTP]).

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

   Key Config {
     Key Config Item With Length (..) ...,
   }

   Key Config Item With Length {
     Key Config Item Length (16),
     Key Config Item (..),
   }

   Key Config Item {
     Key Identifier (8),
     PSK (128),
     HPKE KEM ID (16),
     HPKE Public Key (Npk * 8),
     HPKE Symmetric Algorithms Length (16) = 4..65532,
     HPKE Symmetric Algorithms (32) ...,
   }

   HPKE Symmetric Algorithms {
     HPKE KDF ID (16),
     HPKE AEAD ID (16),
   }

                       Figure 2: Configuration Format

   The format consists of one or more Key Config Items, each prefixed
   with a 16 bit length, in network byte order.

   Each Key Config Item 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.

   PSK:  A 16 byte sequence of bytes of the pre-shared key.

   HPKE KEM ID:  A 16 bit value that identifies the Key Encapsulation
      Method (KEM) used for the identified key as defined in Section 7.1
      of [HPKE] or the HPKE KDF IANA registry
      (https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids).

Thomson                  Expires 25 January 2027                [Page 5]
Internet-Draft        WebPush Encryption using HPKE            July 2026

   HPKE Public Key:  The public key used by the user agent.  The length
      of the public key is Npk, which is determined by the choice of
      HPKE KEM as defined in Section 4 of [HPKE].  (As a result,
      knowledge of the KEM is necessary to process subsequent fields.)

   HPKE Symmetric Algorithms Length:  A 16 bit integer in network byte
      order that encodes the length, in bytes, of the HPKE Symmetric
      Algorithms field that follows.

   HPKE Symmetric Algorithms:  One or more pairs of identifiers for the
      different combinations of HPKE KDF and AEAD that the user agent
      supports:

      HPKE KDF ID:  A 16 bit HPKE KDF identifier as defined in
         Section 7.2 of [HPKE] or the HPKE KDF IANA registry
         (https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kdf-
         ids).

      HPKE AEAD ID:  A 16 bit HPKE AEAD identifier as defined in
         Section 7.3 of [HPKE] or the HPKE AEAD IANA registry
         (https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-
         ids).

5.  HPKE-Encrypted Push Message Format

   The format of push messages when using HPKE is illustrated in
   Figure 3.

   HPKE-Protected Push Message {
     Key Identifier (8),
     HPKE KEM ID (16),
     HPKE KDF ID (16),
     HPKE AEAD ID (16),
     Encapsulated KEM Shared Secret (8 * Nenc),
     HPKE-Protected Message Contents (..),
   }

                Figure 3: HPKE-Protected Push Message Format

   This format is identical to that in Section 4.1 of [OHTTP] and it
   uses a similar construction following the guidance of Section 4.6 of
   [OHTTP], differing only in that it includes a pre-shared key.
   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.

Thomson                  Expires 25 January 2027                [Page 6]
Internet-Draft        WebPush Encryption using HPKE            July 2026

5.1.  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 KEM identified by kem_id,

   *  the pre-shared key from the configuration, psk,

   *  the public key from the configuration, pkR, and

   *  a combination of KDF, identified by kdf_id, and AEAD, identified
      by aead_id, that the application selects from those in the key
      configuration.

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

   1.  Construct a message header, hdr, by concatenating the values of
       key_id, kem_id, kdf_id, and aead_id, as one 8-bit integer and
       three 16-bit integers, respectively, each in network byte order.

   2.  Build info by concatenating the ASCII-encoded string "webpush
       message", a zero byte, and the header.

   3.  Create a sending HPKE context by invoking SetupPSKS()
       (Section 5.1.2 of [HPKE]) with the public key of the receiver
       pkR, info as constructed, the pre-shared key psk, a single byte
       pre-shared key identifier containing a single key_id.  This
       yields the context sctxt and an encapsulation key enc.

   4.  Encrypt msg by invoking the Seal() method on sctxt (Section 5.2
       of [HPKE]) with empty associated data aad, yielding ciphertext
       ct.

   5.  Concatenate the values of hdr, enc, and ct, yielding an encrypted
       push message push_message.

   Note that enc is of fixed-length, so there is no ambiguity in parsing
   this structure.

   In pseudocode, this procedure is as follows:

Thomson                  Expires 25 January 2027                [Page 7]
Internet-Draft        WebPush Encryption using HPKE            July 2026

   hdr = concat(encode(1, key_id),
                encode(2, kem_id),
                encode(2, kdf_id),
                encode(2, aead_id))
   info = concat(encode_str("webpush message"),
                 encode(1, 0),
                 hdr)
   enc, sctxt = SetupPSKS(pkR, info, psk, [key_id])
   ct = sctxt.Seal("", msg)
   push_message = concat(hdr, enc, ct)

5.2.  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, kem_id, kdf_id, aead_id, enc,
       and ct (indicated using the function parse() in pseudocode).  The
       user agent is then able to find the HPKE private key, skR, and
       pre-shared key, psk.

       a.  If key_id does not identify a key matching the type of
       kem_id, the user agent discards the message.

       b.  If kdf_id and aead_id identify a combination of KDF and AEAD
       that the user agent is unwilling to use with skR, the user agent
       discards the message.

   2.  Build info by concatenating the ASCII-encoded string "message/
       bhttp request", a zero byte, key_id as an 8-bit integer, plus
       kem_id, kdf_id, and aead_id as three 16-bit integers.

   3.  Create a receiving HPKE context, rctxt, by invoking SetupPSKR()
       (Section 5.1.2 of [HPKE]) with enc, skR, info, psk, and a one
       byte pre-shared key ID containing key_id.

   4.  Decrypt ct by invoking the Open() method on rctxt (Section 5.2 of
       [HPKE]), with an empty associated data aad, 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:

Thomson                  Expires 25 January 2027                [Page 8]
Internet-Draft        WebPush Encryption using HPKE            July 2026

   key_id, kem_id, kdf_id, aead_id, enc, ct = parse(enc_request)
   info = concat(encode_str("message/bhttp request"),
                 encode(1, 0),
                 encode(1, key_id),
                 encode(2, kem_id),
                 encode(2, kdf_id),
                 encode(2, aead_id))
   rctxt = SetupBaseR(enc, skR, info, psk, [key_id])
   msg, error = rctxt.Open("", ct)

6.  Mandatory Algorithms

   All implementations of this specification MUST implement the
   following algorithms:

   *  the MLKEM768-X25519 KEM (0x647a) Section 8.2 of [HPKE-PQ]

   *  the TurboSHAKE128 KDF (0x0012) Section 5 of [HPKE-PQ]

   *  the AES-GCM AEAD (0x0001) 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.

   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.

Thomson                  Expires 25 January 2027                [Page 9]
Internet-Draft        WebPush Encryption using HPKE            July 2026

   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.

8.1.  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.

8.2.  Multi-Target Ciphertexts in RFC 8291

   RFC 8291 [RFC8192] is vulnerable to an attack where a malicious
   application can construct a single ciphertext that will be decrypted
   successfully (that is, the AEAD tag is accepted) by multiple
   recipients, each of whom can receive a different plaintext.

   This format is also vulnerable to this attack.It is possible to apply
   the techniques from [CDJZ] to achieve this outcome with only modest
   amounts of computation.

   This attack has no practical consequence, as it requires that the
   attacker have information that would allow it to send any message
   without any need to a share a ciphertext.

Thomson                  Expires 25 January 2027               [Page 10]
Internet-Draft        WebPush Encryption using HPKE            July 2026

8.3.  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.

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.3
   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

10.1.  Normative References

   [HPKE]     Barnes, R., Bhargavan, K., Lipp, B., and C. A. Wood,
              "Hybrid Public Key Encryption", Work in Progress,
              Internet-Draft, draft-ietf-hpke-hpke-04, 6 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-hpke-
              hpke-04>.

Thomson                  Expires 25 January 2027               [Page 11]
Internet-Draft        WebPush Encryption using HPKE            July 2026

   [HPKE-PQ]  Barnes, R. and D. Connolly, "Post-Quantum and Post-
              Quantum/Traditional Hybrid Algorithms for HPKE", Work in
              Progress, Internet-Draft, draft-ietf-hpke-pq-05, 6 July
              2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
              hpke-pq-05>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8188]  Thomson, M., "Encrypted Content-Encoding for HTTP",
              RFC 8188, DOI 10.17487/RFC8188, June 2017,
              <https://www.rfc-editor.org/rfc/rfc8188>.

   [WEBPUSH]  Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
              Event Delivery Using HTTP Push", RFC 8030,
              DOI 10.17487/RFC8030, December 2016,
              <https://www.rfc-editor.org/rfc/rfc8030>.

10.2.  Informative References

   [CDJZ]     Cremers, C., Dax, A., Jacomme, C., and M. Zhao, "Automated
              Analysis of Protocols that use Authenticated Encryption:
              How Subtle AEAD Differences can impact Protocol Security",
              USENIX 2023, August 2023.

   [ECH]      Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
              Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
              March 2026, <https://www.rfc-editor.org/rfc/rfc9849>.

   [OHTTP]    Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458,
              DOI 10.17487/RFC9458, January 2024,
              <https://www.rfc-editor.org/rfc/rfc9458>.

   [PQC-GUIDE]
              Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
              T., and M. Ounsworth, "Post-Quantum Cryptography for
              Engineers", RFC 9958, DOI 10.17487/RFC9958, June 2026,
              <https://www.rfc-editor.org/rfc/rfc9958>.

Thomson                  Expires 25 January 2027               [Page 12]
Internet-Draft        WebPush Encryption using HPKE            July 2026

   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [RFC8192]  Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
              and J. Jeong, "Interface to Network Security Functions
              (I2NSF): Problem Statement and Use Cases", RFC 8192,
              DOI 10.17487/RFC8192, July 2017,
              <https://www.rfc-editor.org/rfc/rfc8192>.

   [RFC8291]  Thomson, M., "Message Encryption for Web Push", RFC 8291,
              DOI 10.17487/RFC8291, November 2017,
              <https://www.rfc-editor.org/rfc/rfc8291>.

   [WEBPUSH-SYM]
              Thomson, M., "WebPush Encryption using Symmetric Ciphers",
              24 July 2026.

Acknowledgments

   TODO

Author's Address

   Martin Thomson
   Mozilla
   Email: mt@lowentropy.net

Thomson                  Expires 25 January 2027               [Page 13]