(no title)
kgraney | 3 years ago
We’ve been calling this problem key consistency, basically the risk that Google (or any OHTTP gateway operator) gives out unique keys to different users and builds a {user -> request} mapping based on the keys used to encrypt requests. The OHTTP authors published a draft spec discussing exactly this problem. https://datatracker.ietf.org/doc/draft-ietf-privacypass-key-...
Frankly, none of the technical solutions we considered were satisfying enough given the added complexity. It’s actually kind of tricky to form a convincing distribution model. The designs we looked at mostly involve multi-party schemes where there’s trust required either that parties don’t collude with each other or between the user and one party explicitly. Admittedly OHTTP is also premised on multiple parties not colluding, but we decided to punt on the key consistency problem for the sake of simplicity. We also recognize that it’s possible for savvy users to fetch the keys from the endpoints we’re serving them on, compare those keys with other users, and fact check our claims. We honestly have nothing to hide about this; everyone is receiving the same key.
To specifically address the two proposals you made:
1) Shipping the key with the client: it’s not clear this is any better than fetching it right from Google. Chrome updates and our experiment framework (known as Chrome Variations) are both Google-managed distribution mechanisms, not terribly different from fetching the key at a Google API endpoint.
2) Having the relay serve the keys: these keys are actually designed to protect data from the relay. If the relay could change the public key Chrome uses to something the relay knows the private key for it would undermine the purpose of HPKE encryption. You suggested the relay could serve a key signed by Google. The issue with that is it complicates the process of key revocation. We expect to rotate the key we use, and we want to maintain the ability to revoke keys if needed (say the relay learned of a private key). Sure we could serve a signing key revocation list, but then we’re back in into the world of complicating the multi-party relationships.
All this being said, addressing key consistency issue is on our radar, and we hope to improve the distribution model in the future. We welcome feedback of course; and we’ll take it into consideration as we continue to evolve the designs used here. There is a general blog post on Privacy Sandbox feedback at [1] and you can take a look at specifically how Chrome is fetching keys in [2]. In case you're curious the key we’re serving today has a cipher suite of (DHKEM_X25519_HKDF_SHA256, HKDF_SHA256, AES_256_GCM) and at the moment we have two gateways (one for read traffic and one for write traffic) each using their own single keypair.
[1]: https://developer.chrome.com/docs/privacy-sandbox/feedback/
[2]: https://source.chromium.org/chromium/chromium/src/+/main:chr....
garblegarble|3 years ago