what motivated the design decisions of RFC 8291 ("Message Encryption for Web Push")?

Question

Related question here.

I'm reading RFC 8291, which describes a protocol to protect web push messages sent between an application server and a user agent (typically a mobile browser or other mobile application), using an untrusted "push service" (think APNS or FCM) as an intermediary. The constraints appear to be as follows:

1. The user agent and the application server are assumed to have an out-of-band secure channel for initial setup (typically a direct TLS connection)
2. After initial setup, the application server needs to be able to asynchronously send messages to the user agent, achieving confidentiality and integrity

The RFC takes what seems to be a fairly complex route to solving this problem, using three different primitives: elliptic-curve Diffie-Hellman, HKDF, and AES-GCM:

1. During the initial handshake, the user agent generates a long-lived ECDH keypair and symmetric secret, then sends them to the application server over the secure channel
2. To send a message, the application server:
   1. Generates an ad-hoc ECDH keypair and carries out ECDH with the user agent's public key, deriving a shared secret
   2. Combines this ad-hoc shared secret with the long-lived symmetric secret using HKDF, deriving a key
   3. AEADs the message with AES-GCM and sends it to the push service, which relays it to the user agent

As I understand it, ECDH is used for confidentiality and the symmetric secret is used for integrity (it authenticates the server to the client). One might think that ECDH is also used to achieve forward secrecy. But technically, this protocol is not forward-secret, since there is a long-term key (the private half of the user agent's ECDH keypair) that can be used to decrypt any message.

My question is: how does this protocol improve on transmitting a single symmetric key over the secure channel, then sending messages protected by a single AEAD (XChaCha20-Poly1305 seems especially attractive for this use case)? Is it because the user agent's private key is thought to be harder to attack than a symmetric shared secret (e.g., because individual client devices are harder to attack, or because it can be stored in a secure coprocessor)?

Answer 1

Although it is not forward secure against client-side compromise (i.e. disclosure of the user agent's long term private key), it is forward secure against server-side compromise (i.e. disclosure of all information available to the server).

Thus, for example, if ownership of the application server is transferred from one company to another and the user's trust relationship with the new company is not as strong as the old company, the user still has assurance that their old messages are not compromised.

Bidirectional forward security would seem to be preferable, but the the offline encryption implications of push messaging make this a constraint that is hard to achieve.