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:
- 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)
- After initial setup, the application server needs to be able to asynchronously send messages to the user agent, achieving confidentiality and integrity
- 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
- To send a message, the application server:
- Generates an ad-hoc ECDH keypair and carries out ECDH with the user agent's public key, deriving a shared secret
- Combines this ad-hoc shared secret with the long-lived symmetric secret using HKDF, deriving a key
- 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)?