1
$\begingroup$

I'm reading RFC8291. Here's a figure on how Web Push Notifications work in general:

    +-------+           +--------------+       +-------------+
    |  UA   |           | Push Service |       | Application |
    +-------+           +--------------+       +-------------+
        |                      |                      |
        |        Setup         |                      |
        |<====================>|                      |
        |           Provide Subscription              |
        |-------------------------------------------->|
        |                      |                      |
        :                      :                      :
        |                      |     Push Message     |
        |    Push Message      |<---------------------|
        |<---------------------|                      |
        |                      |                      |

                                 Figure 1

Then, RFC8291 adds cryptography on top of it. If I understood correctly:

  1. In the "Provide Subscription" step, the User Agent (UA) and the Application both agree on a shared secret using ECDH.
  2. Then, when the Application wants to send a push notification to the UA, it encrypts symmetrically (via AES) the notification content using the shared secret.
  3. The Push Service relays this encrypted notification to the UA.
  4. The UA decrypts the notification content using the shared secret.

My question is: why use ECDH when simple asymmetric encryption/decryption can be used?

  1. UA generates a private/public key pair.
  2. In the "Provide Subscription" step, the UA sends its public key to the Application.
  3. The Application, when it wants to send a push notification, encrypts the notification content with UA's public key.
  4. Same as before, the Push Service, relays the encrypted message.
  5. The UA decrypts the encrypted notification content with its private key.

What are the trade-offs between the method I described here, and the one in the RFC?

Improve this question
$\endgroup$
1
  • 1
    $\begingroup$ Apparently the designers preferred not having to perform asymmetric cryptographic operations for each push notification... $\endgroup$
    – SEJPM
    Commented Sep 20, 2020 at 17:54

1 Answer 1

Reset to default
2
$\begingroup$

Your alternate method has an expensive public key operation for each push message. While the first protocol does a key exchange just once per subscription and then continues with a symmetric key.

If in the key exchange both sides authenticated themselves (Or at least the Application) the user can rely on this, if authenticated encryption is used it still a fast symmetric key operation to decrypt and authenticate the message.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Something one may want to consider to emphasize here additionally to the performance cost: Because the additional key exchange is authenticated for both parties, all subsequent symmetric messages are as well whereas with asymmetric encryption you'd need to involve even more public key crypto to get sender authentication... $\endgroup$
    – SEJPM
    Commented Sep 20, 2020 at 18:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.