RFC 8291 / START HERE
Web Push encryption, before the details
Message Encryption for Web Push protects the content of notifications. Web Push delivers a message from an application server to a user agent, such as a browser, through a push service.
The application server encrypts the message content before sending it to the relay. The user agent derives the same key and authenticates and decrypts the content. Public header values help it do so without giving the push service the subscription secrets.
Why it exists
Protecting the HTTP connections to a relay does not hide content from that relay. RFC 8291 combines subscription secrets, Elliptic Curve Diffie-Hellman (ECDH) key agreement and the RFC 8188 encrypted content coding to protect the message end to end. HTTP headers, timing and routing information still have important limits.
A familiar example
A fictional weather app wants to send a forecast through a shared push service. Its browser first provides subscription key material to the authorized weather server over a protected channel. The server encrypts a record; the browser checks it before delivering the forecast. The chapters show the secret ownership, key schedule, record fields, rejected messages and body-size budget.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Distribute the subscription secrets safelyA user agent, such as a browser, receives messages through a push service. Its application shares subscription material only with an authorized application server.→
- Derive the same ECDH secret at both endsThe sender creates a fresh P-256 key pair for a message. Each endpoint combines its own private key with the other endpoint’s public key.→
- Bind the shared secret to this subscriptionThe first HMAC-based Key Derivation Function (HKDF) stage combines the ECDH result with the subscription authentication secret and an ordered context.→
- Derive a per-message key and nonceA second extraction uses the public message salt and the IKM. Separate labels then derive the content-encryption key and nonce.→
- Authenticate one record before delivering bytesThe HTTP body carries a clear binary header followed by one encrypted record. The receiver must authenticate the record and check its final padding delimiter.→
- Budget the body and keep the privacy limitsEncryption protects message content, while the relay still sees clear headers, sizes, timing and routing relationships. Padding also consumes the message budget.→
This introduction explains RFC 8291 (2017). Read the original RFC ↗