| title | IPIP-0421: HTTP Delegated Routing Reader Privacy Upgrade | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| date | 2023-05-31 | ||||||||||||||||||||
| ipip | ratified | ||||||||||||||||||||
| editors |
|
||||||||||||||||||||
| order | XXX | ||||||||||||||||||||
| tags |
|
This IPIP specifies new HTTP API for Privacy Preserving Delegated Content Routing provider lookups.
IPFS is currently lacking of many privacy protections. One of its main weak points lies in the lack
of privacy protections for the Content Routing subsystem. Currently neither Readers (clients accessing files)
nor Writers (hosts storing and distributing content) have much privacy with regard to content they publish or
consume. It is very easy for a Content Router or a Passive Observer to learn which file is requested by
which client during the routing process, as the potential adversary easily learns about the requested CID.
A curious actor could request the same CID and download the associated file to monitor the user’s behavior.
This is obviously undesirable and has been for some time now a strong request from the community.
The latest upgrades to the DHT and IPNI have introduced Double Hashing - a technique that aims to better preserve Reader Privacy.
With Double Hashing in place Provider Records are encrypted and opaque to Content Routers. If presented with the original CID a
Content Router can decrypt the relevant Provider Records and serve them via the existing Delegated Routing API.
However in order to benefit from the privacy enhancement users need to change the way they interact with Content Routers, in particular:
- A second hash over the original
Multihashmust be used when looking up the content; - Returned Provider Records are encrypted and must be decrypted by the client before using them;
- The client might choose to fetch additional encrypted Metadata from the Content Router.
This new way of interaction can not be fullfilled by the existing API. This IPIP is an incremental improvement to the HTTP Delegated Routing API that adds new endpoints for serving encrypted content. The original API can still be used for not Privacy Preserving lookups.
Writer Privacy is out of scope of this IPIP and is going to be addressed separately.
See the Delegated Routing Reader Privacy Upgrade spec (:cite[http-routing-reader-privacy-v1]) included with this IPIP.
This API proposal makes the following changes:
- Adds new methods for looking up encrypted Provider Records and encrypted Metadata;
- Defines Hashing and Encryption functions and response payloads structure.
There are no ideomatic changes to the API - all data formats, design rationale and principles outlined in the original HTTP Delegated Routing IPIP apply here.
With the new APIs users can protect themselves from:
- a malicious actor spying on the user by observing the user to Content Router traffic and then downloading the same data;
- the new API is a first step towards fully private HTTP Delegated Routing protocol that will eliminate IPNI as centralised observers.
There are no other functional improvements.
Users will need to explicitly turn on Reader Privacy on their nodes. A new flag can be introduced to the Kubo's HTTP Delegated Content Router configuration to facilitate that functionality. Users on older nodes can continue using the old API and turn on reader Privacy at a alter point.
Content Routers should provide the same QoS for both Privacy Preserving and regular APIs. This is because both can be served over the same encrypted data. If presented with a regular CID, a Content Router can perform decryption operations on behalf of the user (i.e. mimic the client logic) and return results in clear text. If presented with a second hash the Content Router can return encrypted results and let the user to do decryption themselves.
It's possible that not all Content Routers will adopt Reader Privacy. The default HTTP Delegated Router like cid.contact should have Reader Privacy enabled by default in the newer versions of Kubo / Helia.
Users should verify themselves whether a custom router of their choice supports Reader Privacy or not when configuring it.
The /routing/v1/encrypted/ API will be implemented in boxo/routing/http and will not introduce any breaking changes to existing clear text endpoints.
The API will be released in a new minor version.
Reader Privacy relies on usage of specific hashing and encryption functions. Function rotation will require a network-wide migration. Content Routers might not be able to migrate "under the hood" as they don't possess the original values. Function rotation should be a very infrequent event and will require network-wide efforts. When function rotation is needed - a version of the API will be incremented.
Copyright and related rights waived via CC0.