Re: [push-api] Message encryption (#130)

>> If we are exporting keys, we need to ensure that we have a constant time string conversion for ArrayBuffer.

> Excuse my naitivity, but why does this matter? The client-side already has access to the raw key using getKey, and given that the key is bound to the origin that shouldn't be timing sensitive. The server-side can thus receive the key in either format. Since we rely on the client-server connection being secure for transporting the key (HTTPS), does the timing sensitivity occur if the server were to store the key in, say, base64?
> 
> If the concern is that the client-server connection could be intercepted, then this problem could be attributed to the public key having to stay private more than timing sensitivity of serialization, right?

I've been planning to more precisely articulate the concerns that your colleagues raised, which are:

1. Authentication of the application server relies on the application (as a whole) maintaining the confidentiality of one of the endpoint URL or the public key.  Leak both of these, and messages can be sent to the user agent.  If you leak one, the endpoint is perhaps more serious, because it can allow an attacker to send messages to the endpoint, which will drain battery, even if they aren't delivered.
2. These two values are not generally treated as secrets.

A URL is - in many contexts - leaked all over the place.  Even if we don't consider things like Referer to be relevant in this context, we have to concern ourselves with the potential for non-constant-time encoding and decoding of strings.  For example, translation between UTF-16 and UTF-8 happens all over the place in a browser and if that translation leaks bits of the URL into a timing side channel, it could be bad.  Of course, I'm not aware of any timing channel that reveals any difference between the usual base64 URL-safe alphabet characters, but my understanding is that this is primarily a principled position rather than a concern based on a specific attack.

Similarly, a public key is not treated with the same care as a private key.  Therefore, again, there might be leaks.  In this case, a specific concern arises if base64 encoding is used, because base64 is likely to have subtle timing differences that can leak information.  Similarly, a naive hex encoding implementation will leak bits when the upper nibble of a byte is zero.  Regarding other timing channels, as Adam noted, there are few implementations that treat public keys in a timing-dependent manner, but see above regarding principle.

Note that we have to be very careful about things like timing side channels in the browser.  Unintentionally leaking information to other origins, especially when it is supposed to be secret, is not good.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/pull/130#issuecomment-134679953