[Jmap] Re: Working group last call draft-ietf-jmap-webpush-vapid

[Phillip Tao <[e-mail]>]

> On Aug 1, 2024, at 4:21 AM, Daniel Gultsch <[e-mail]> wrote:
> 
> I've made an update to draft-ietf-jmap-webpush-vapid that explains how
> key rotations should be handled.

I think the new text in section 4 is good, but doesn't fully address the race condition. The "application server key that was advertised in the capabilites [sp] object at the time	the PushSubscription was created" may not be the application server key that the client used to create the push subscription. The key may have rotated between when the client last fetched the Session and when they created the PushSubscription. With no intervening requests, it would not know that the application server key has changed.

I think it would also be good to add some text for how the JMAP server should handle a 403 from the push server, specially for/possibly only for the PushVerification.
> 
> On Fri, Jul 26, 2024 at 5:31 PM Phillip Tao <[e-mail]> wrote:
>> 
>> My slight concern with 3(b) is that one reason you may want to rotate your key is that it was compromised. Knowingly continuing to use a key that's compromised seems a little odd, and it generally seems more prudent to immediately notify the user agent that they need to recreate their push subscriptions, so they don't receive fraudulent/dangerous push notifications. I wonder if this is why RFC 8292 chose to recommend that the application server prompt the client to create a new subscription.
> 
> (Web)Push Encryption, which is already specified in RFC 8620 should be
> used to protect against fraudulent push notifications.

That makes sense.

> VAPID (in my
> understanding) is mostly used as a mechanism for push services to
> protect against (D)DoS.

It protects against DDoS by requiring authentication to push. If the key is compromised, it effectively is the same as not having VAPID.

> So if your application server key would leak
> and an attacker would abuse it it would probably "just" get blocked by
> the push service.

To block the application server, the push service needs to distinguish legitimate and fraudulent push messages. They may not always get it right (for example, they may be relying on suspicious volume as an indicator, and so the first few messages may get through). I imagine some push services may exempt VAPID push subscriptions from the same spam detection that non-VAPID subscriptions would be subject to.

> I don’t see any immediate harm for a JMAP server to
> continue using a rotated key for a certain period of time.

Since JMAP push subscriptions require encryption, I agree.

> Also to my
> knowledge there is no system in place to revoke VAPID keys with any of
> the major push services. So even if the JMAP server would stop using
> it an attacker could continue to use it until the push URL expires
> (which may or may not happen when the user agents request a new URL)

Hence why I suspect that RFC 8292 recommends the application server prompt the client to recreate the push resource (which I think would imply DELETEing the old one).
> 
> I think it’s good that we specified how key rotation works (Thank you
> Bron for bringing this up) but personally I’m seeing this mostly as a
> means to recover from key loss rather than compromise.

Sure, I think that's likely the more common case, I just wanted to make sure we're not opening up additional "security considerations" in the odd compromise case. But I think the encryption requirement covers that.
> 
> cheers
> Daniel