Re: [Privacy-pass] Questions on client trust

[Alex Davidson <[e-mail]>]

Hi Chelsea & Matt,

Thanks for taking the time to review the current documents. Your insights are really valuable and raise a number of points that do indeed require addressing. I’ve inlined my responses below.

> On 14 Apr 2020, at 03:14, Chelsea Komlo <[e-mail]> wrote:
> 
> Hi all,
> 
> We are submitting this feedback as core contributors of the Tor Project (although not speaking on behalf of Tor), to assess the draft for user privacy and anonymity. We are happy to continue providing reviews going forward from this angle.
> 
> We will start with a few meta-comments, and then discuss Alex's points in-line.
> 
> First, the draft targets "privacy-preserving authorization", however, if clients do not use a network anonymity tool such as Tor, clients can be trivially tracked (ignoring all proposals that place complete trust in single entities such as IP blindness or VPNs). Hence, we assume that users of anonymity networks such as Tor are a core motivating use case of Privacy Pass (as they were for the original paper). We suggest adding Tor users to a "Motivating Use Cases" section to the draft (and other noteworthy cases) to ensure this use case is not lost throughout the standardization process. 

Agreed, the motivating use-cases in the original paper have not made it explicitly into the current documents so far. Adding such a section on motivating applications that includes the Tor use-case makes sense and I’ve created a github issue to track this [1].

> Second, we note the change of wording in the draft from "anonymously authorizing" to "privacy-preserving authorization". We recommend using the phrasing "anonymously authorizing" due to its stronger guarantees to end users. 

In principle, I would personally be fine with replacing "privacy-preserving” with “anonymously”. I think this also relates to something that was highlighted previously regarding establishing a better definition of the “anonymity" guarantee that we expect throughout the drafts. I’ve added an issue to track both of these things together [2].

> Third, we wish to highlight the lack of detail on trusted registries and the potential harm to users that could occur if registries cannot not be trusted. If registries are secretly malicious, users can be trivially tracked (by the registry colluding with malicious issuers to distribute unique public keys). As such, we suggest adding stronger mechanisms to the draft to ensure registry trust. 

I agree that trusted registries are still not very well-defined. I expect that, if we decide to go down the trusted registry route, the user-registry trust dynamic will be similar to the trust dynamic between user and Issuer. We will need mechanisms for the clients to ascertain the state of this dynamic and subsequently act on that. Ideally, we would have some more discussion on whether the trusted registry approach is the right path to take, or whether an alternative approach may be better suited (such as those raised by Steven in the BoF).

> Fourth, we suggest adding a strict upper bound to the number of bits of information that can be encoded into tokens, if this capability is added to the draft or an extension. Clearly, the larger the number of possible anonymity sets, the more fingerprintable users become. Consequently, we suggest upper bounding this number, and to keep it small.

Adding an analysis on the impact of adding additional metadata to tokens to the next iteration of the drafts is a necessity (created another issue to track this [3]). In practice, I agree that the amount of viable bits of metadata that can be added is going to be very low (e.g. <= 2). However, on specifying a strict upper bound, this may be more difficult. This is because the impact of adding metadata impacts the client’s privacy budget in essentially the same way that introducing more Issuers does, or reducing the total number of clients does. 

Currently, I’m slightly leaning towards putting a strict lower bound on the size of the effective anonymity set for any given user in an ecosystem, and offering different configurations that support this lower bound. For example, if an ecosystem only contains 2 Issuers, then you may be able to sanction 2 bits of metadata per token. If you construct an ecosystem with 4 Issuers, then maybe the number of sanctioned metadata bits is 1 or 0. Of course, these configurations will naturally imply an upper bound on the number of bits that are supported, but this approach may be slightly more flexible?

> On Thu, Apr 2, 2020 at 4:44 AM Alex Davidson <adavidson=[e-mail] <mailto:[e-mail]>> wrote:
> Hi all,
> 
> Following on from the previous email. There were some initial questions
> raised during the BoF that will be important to discuss before we
> proceed to rework the charter. The most immediate questions are the
> following:
> 
> - To what extent should client's trust the issuers when redeeming
> tokens?
>         - Under what conditions should they accept/redeem tokens?
>         - What information does the client trust the issuer to encode in the
>         tokens?
> - How does an ecosystem protect itself against issuer consolidation
> and/or centralization?
> 
> The first point is not currently covered by the current charter or docs.
> For example, a helpful measure would be for the client to check the size
> of the anonymity set that it is part of. Such considerations are
> required to be made for any client looking to use an
> anonymity-preserving tool. However, checking such measures appears
> difficult in the ecosystem that we are looking to construct. There are
> currently only recommendations in the architecture doc for redeeming
> tokens to reduce the impact of an issuer being able to target a specific
> client. I think providing practical mechanisms for allowing clients to
> make decisions on which issuers to trust is something that we will be
> able to do (such as specifying client/consumer allow-lists). But,
> providing the actual measures that the client uses to make these
> decisions appears (at least to me) to be beyond the scope of what can be
> achieved with the current design.
> 
> While indeed the task of ensuring client trust requires adding additional details to this draft, it is critical to ensure its effectiveness for its intended use case. 
> 
> For users to be sure they are part of a sufficiently large anonymity set, they should be sure that 1) their tokens do not have a large number of bits encoded into them, 2) their registry is trustworthy, and 3) the issuer that a user holds tokens from has issued a sufficiently large number of tokens to other users. The first two points can be reasonably verified from a user side; thus, we suggest including such mechanisms in the draft. The last point (regarding number of tokens an issuer has distributed) seems harder, but should be given more thought. 

On point 3), I currently don’t have a great grasp on what a solution may look like. Perhaps there could be some way of incorporating a client gossip protocol with a set of client-specified trusted peers? However, this may also open up further possibilities for centralisation if all clients decide to use the same trusted peers?

Thanks,
Alex

[1]: https://github.com/alxdavids/privacy-pass-ietf/issues/9 <https://github.com/alxdavids/privacy-pass-ietf/issues/9>
[2]: https://github.com/alxdavids/privacy-pass-ietf/issues/10 <https://github.com/alxdavids/privacy-pass-ietf/issues/10>
[3]: https://github.com/alxdavids/privacy-pass-ietf/issues/11 <https://github.com/alxdavids/privacy-pass-ietf/issues/11>