Re: [w3c/push-api] Some things about the PushEncryptionKeys p256dh and auth are not clear enough (#212)

> The getKey() method is a required for an implementation of the Push API, so the auth and p256dh fields must be supported too. Would updating the cited sentence to the following clarify the statement?
> 
> > Keys named p256dh and auth must be supported, and their values must correspond to those necessary for the user agent to decrypt received push messages in accordance with [WEBPUSH-ENCRYPTION].

Yes, I think that would make it clearer

---

> In Chrome, we introduced support for encrypted payloads in version 50 by adding the getKey() method, updating the PushSubscription serializer and lazily creating keys for subscriptions created prior to that release. I guess new, partial implementations could do something similar. This would significantly impact their interoperability story, so it's undesirable at best.

In some instances, this could be very problematic – for example: In one of my planned use cases, website visitors don't have a local account, if they want notifications they just press a toggle button on the site. So, then my server gets the endpoint, the auth-key-value/null and p256dh-key-value/null and that's it. To later set/update the settings of an existing notification or remove notifications, the browser now gives the endpoint to my webpage as “authentication”. That works, but is not very secure. For example, if there is a small push service which distributes very short endpoints it could be possible to brute force endpoints until a valid endpoint is found (which would be slowed down by brute force protection and you only would get access to a random endpoint-“account” but still with enough effort, it wouldn’t be impossible). Additionally, the more endpoints register, the higher the chance to find a valid endpoint per brute force attempt. To make this safer, I’d like to hash the auth-key and send this as second authentication characteristic, so that an attacker would have to exactly guess an endpoint + auth-key-hash combination. If there are then more endpoints, the auth-key-hash would still provide the same security (because different endpoints could theoretically have the same auth-key-hash). But this only works if I can be totally sure, that an endpoint without keys would always trigger pushsubscriptionchange as soon as endpoint-keys are added and that existing keys are not changed without calling pushsubscriptionchange. 

---

> The keys are associated with the subscription and should not change during its lifetime. If the user agent has to update them, the pushsubscriptionchange event should be used to communicate this to the developer. It'll be considered an entirely new subscription at that point.
> I think step 15 of the subscribe() algorithm details this. It's the only place where a key pair is created.

Step 15 in the editor draft from 18. August 2016 is:

> Generate a new P-256 ECDH key pair. Store the private key in an internal slot on subscription; this value must not be made available to applications. The public key is also stored in an internal slot and can be retrieved by calling the getKey method of the PushSubscription with an argument of p256dh.

So, while you could assume that the keys should not change, it is nowhere written down, which doesn't make it a good idea or safe to rely on.

How about adding something like?:

> If Keys named p256dh and auth of an push subscription are to be changed or added after the subscribe method is finished, this MUST result in calling pushsubscriptionchange

or if you don't want to let this result in a completely new subscription, you could add a small and simple function like pushsubscriptionkeyupdate, which basically would get the "old" subscription and a new one with updated keys.

Thanks for your support :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/212#issuecomment-256161719