Subject: [Privacy-pass] Questions on client trust

From: Alex Davidson <[email-masked]>
Date: Thu, 2 Apr 2020 11:44:19 +0100

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.

On the second point of consolidation/centralization, this relates to the
open question of how issuers are monitored by the ecosystem. The
mechanism that we have for managing issuer key material in the
architecture doc introduces a degree of centralization because the
configuration registry must be centrally operated. The practical
mechanisms used by clients to determine which issuers are trusted may
also contribute to this. During Steven's presentation he mentioned some
alternatives to this solution, such as fetching key material directly
from issuers or from an intermediate proxy. However, both approaches
would still need some sort of auditing. This could perhaps be avoided by
introducing some sort of decentralization, though it's not immediately
clear to me what such a solution would look like?

Thanks,
Alex

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 6 Apr 2020 14:57:16 -0400

> - How does an ecosystem protect itself against issuer consolidation

Since we are chartering, not designing, I think it's premature to try to
solve these problems.  At this stage, our goal should be to describe (1)
the problems and (2) the scope of our ambition to address them.

As often seems to be the case, I think we are not really talking about
"more" or "less" consolidation, but rather trading off consolidation
pressure in different elements of the ecosystem.  The charter should
acknowledge that some degree of consolidation pressure may be unavoidable,
but we will do our best to minimize and mitigate it.

> achieved with the current design.

As several people seem to have noted, if origins ("forwarding verifiers")
could commit globally to a small set of issuers (of which the client
chooses only one), this might allow the client to convince themselves that
offering a token reduces their anonymity by at most some bounded amount.

Alternatively, perhaps a double-blinded exchange could allow the client to
provide a validation token from one of the verifier's trusted issuers,
without enabling the verifier to identify _which_ issuer it was.

> configuration registry must be centrally operated.

The unified central registry is not the only concern, perhaps not even the
main one.  I think the greater concern is the architecture draft's noted
restriction that: "allowing no more than 4 issuers at any one time is
highly preferable", which I believe is independent of the method of
auditing.  The reasoning behind this restriction seems sound, but the
resulting limit is unfortunate, and we should look for ways to remove it.

The practical
> --
> Privacy-pass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>

---

From: Chelsea Komlo <[email-masked]>
Date: Mon, 13 Apr 2020 20:14:07 -0600

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.

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.

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.

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.

> 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.

Thanks,
Chelsea Komlo and Matt Finkel

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 14 Apr 2020 12:43:36 +1000

On Tue, Apr 7, 2020, at 04:57, Ben Schwartz wrote:
> On Thu, Apr 2, 2020 at 6:44 AM Alex Davidson 
> <adavidson=[email-masked]> wrote:
> Since we are chartering, not designing, I think it's premature to try 
> to solve these problems. At this stage, our goal should be to describe 
> (1) the problems and (2) the scope of our ambition to address them.

I think that this cuts to the core of the question of feasibility.  That is, is this a research project or an engineering task?

There are two paths that avoid having to deal with these questions:

1. pick a single manifestation of the system, like "is human", build to that, and document this

2. make it very clear that the way in which the token conduit acts is very much subject to some amount of trust in the token issuer, explain that any carriage of token across what might otherwise be a privacy boundary requires that this trust exist, and build the system with that in mind

The original charter might have been a shade more biased toward the latter approach, but the designs I saw included mechanisms that seemed to derive from a viewpoint that had less inherent reliance on trust.  The designs implied (at least to me) an assumption that the conduit didn't need to think or trust.  That might be possible for the "is human" bit in browsers, maybe, so that's not unreasonable.  That made this hard to assess because of those implicit assumptions.
 
> acknowledge that some degree of consolidation pressure may be 
> unavoidable, but we will do our best to minimize and mitigate it. 

This notion of how protocols act to shape market pressures is new for us here, so it might be OK to call it out as special.  We used to do that for security until it was sufficiently internalized.  However, we need to remember that this is just another factor we should each consider as we go through this process.  I don't want to over-rotate on consolidation when we also need to consider environmental impacts, the effect on underrepresented minority groups, accessibility, privacy, or any of a number of other important factors.

The apparent need for trust of certain types in this system does tend to produce certain consolidation pressures that we need to acknowledge, but until we understand the precise role of trust, we can't know for sure.  What is worse, the details of the information being conveyed likely has more of an effect on this than anything else, and it seems like there is a desire to make the information conveyed flexible.

Maybe the consolidation thing is manageable for something like an "is human" assertion, but is completely intractable in the general case.  And maybe that is OK from a consolidation perspective because the protocol is completely unusable at global scale for any other sort of assertion.  And maybe that is terrible because it means the creation of islands of haves and have-nots for privacy pass.  (And maybe I should stop extrapolating from zero information.)

---

From: Alex Davidson <[email-masked]>
Date: Tue, 14 Apr 2020 12:24:41 +0100

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 <[email-masked]> 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=[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
> 
> 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>

---

From: Alex Davidson <[email-masked]>
Date: Tue, 14 Apr 2020 12:50:38 +0100

> On 14 Apr 2020, at 03:43, Martin Thomson <[email-masked]> wrote:
> 

I would rather not scope as narrowly as “is human” as I think some of the proposed applications being considered are somewhat broader than that specific signal. I think the path that is raised in 2) is close to the direction that I was personally imagining that we would take. My preference would be to assume that the client has decided which Issuers/Registries/Vendors that it can trust and then build the protocol and architecture with this trust already established. There may be ways that we can provide broad recommendations on how clients may want to make this decision (e.g. based on the past behaviour of the Issuer in interactions, key rotations etc.) but going beyond that seems beyond the scope of the work, in my opinion.

> Maybe the consolidation thing is manageable for something like an "is human" assertion, but is completely intractable in the general case.  And maybe that is OK from a consolidation perspective bec…

I think these are all valid things to consider regarding the issue of consolidation and its relationship with the trust dynamic between a client and the rest of the ecosystem. I agree with Ben that aiming to minimise this pressure in the design of the protocol architecture is something that we can commit to in the charter. We can then better establish in future documentation exactly how this mitigation would work, and how concerns of the nature that Martin has surfaced interplay with each other. I also agree that making a concrete assertion about the type of signals that the protocol can provide (“is human” or otherwise) is going to be essential in being able to answer these questions.

Alex

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 14 Apr 2020 23:53:06 -0400

I don't understand what "is human" is supposed to mean.  Surely for this
protocol it is always false!  For clarity, I would not want this phrasing
in the charter.

I also don't understand how a transferable, anonymous, single-use token
asserts anything about the holder, or has anything to do with trust.  I
think we should adjust the phrasing there too.  I would prefer to have a
charter that speaks of acquiring and spending unlinkable tokens.

I think we should rule all content (blind signing) strictly out of scope.
The complexity of supporting content is not worth it for N<4 bits; just
encode the content in unary by the choice of issuer.  If that proves too
inefficient after this is all finished, we can consider a follow-on
specification with content.

On Tue, Apr 14, 2020 at 7:50 AM Alex Davidson <adavidson=
[email-masked]> wrote:

> > I think that this cuts to the core of the question of feasibility.  That
> is, is this a research project or an engineering task?
> >
> > 2. make it very clear that the way in which the token conduit acts is
> very much subject to some amount of trust in the token issuer, explain that
> any carriage of token across what might otherwise be a privacy boundary
> requires that this trust exist, and build the system with that in mind
> >
> > The original charter might have been a shade more biased toward the
> latter approach, but the designs I saw included mechanisms that seemed to
> derive from a viewpoint that had less inherent reliance on trust.  The
> designs implied (at least to me) an assumption that the conduit didn't need
> to think or trust.  That might be possible for the "is human" bit in
> browsers, maybe, so that's not unreasonable.  That made this hard to assess
> because of those implicit assumptions.
>
> I would rather not scope as narrowly as “is human” as I think some of the
> proposed applications being considered are somewhat broader than that
> specific signal. I think the path that is raised in 2) is close to the
> direction that I was personally imagining that we would take. My preference
> would be to assume that the client has decided which
> Issuers/Registries/Vendors that it can trust and then build the protocol
> and architecture with this trust already established. There may be ways
> that we can provide broad recommendations on how clients may want to make
> this decision (e.g. based on the past behaviour of the Issuer in
> interactions, key rotations etc.) but going beyond that seems beyond the
> scope of the work, in my opinion.
>
> > This notion of how protocols act to shape market pressures is new for us
> here, so it might be OK to call it out as special.  We used to do that for
> security until it was sufficiently internalized.  However, we need to
> remember that this is just another factor we should each consider as we go
> through this process.  I don't want to over-rotate on consolidation when we
> also need to consider environmental impacts, the effect on underrepresented
> minority groups, accessibility, privacy, or any of a number of other
> important factors.
> >
> > The apparent need for trust of certain types in this system does tend to
> produce certain consolidation pressures that we need to acknowledge, but
> until we understand the precise role of trust, we can't know for sure.
> What is worse, the details of the information being conveyed likely has
> more of an effect on this than anything else, and it seems like there is a
> desire to make the information conveyed flexible.
> >
> > Maybe the consolidation thing is manageable for something like an "is
> human" assertion, but is completely intractable in the general case.  And
> maybe that is OK from a consolidation perspective because the protocol is
> completely unusable at global scale for any other sort of assertion.  And
> maybe that is terrible because it means the creation of islands of haves
> and have-nots for privacy pass.  (And maybe I should stop extrapolating
> from zero information.)
> >
>
> I think these are all valid things to consider regarding the issue of
> consolidation and its relationship with the trust dynamic between a client
> and the rest of the ecosystem. I agree with Ben that aiming to minimise
> this pressure in the design of the protocol architecture is something that
> we can commit to in the charter. We can then better establish in future
> documentation exactly how this mitigation would work, and how concerns of
> the nature that Martin has surfaced interplay with each other. I also agree
> that making a concrete assertion about the type of signals that the
> protocol can provide (“is human” or otherwise) is going to be essential in
> being able to answer these questions.
>
> Alex
>
> --

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Apr 2020 21:09:05 -0700

On Tue, Apr 14, 2020 at 8:53 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

> asserts anything about the holder, or has anything to do with trust.
>

Really? The motivating example seems like it is asserting that the holder
has passed some CAPTCHA.

I think we should adjust the phrasing there too.  I would prefer to have a

> specification with content.

A number of the obvious applications of this kind of technology require
content and probably > 4 bits. I don't think we should go to the trouble of
designing a protocol as inflexible as you suggest.

-Ekr

> [email-masked] <[email-masked]>> wrote:
>
>>
>> >> (1) the problems and (2) the scope of our ambition to address them..
>> >
>> > I think that this cuts to the core of the question of feasibility.
>> That is, is this a research project or an engineering task?
>> >
>> interactions, key rotations etc..) but going beyond that seems beyond the
>> > This notion of how protocols act to shape market pressures is new for
>> us here, so it might be OK to call it out as special.  We used to do that
>> for security until it was sufficiently internalized.  However, we need to
>> > The apparent need for trust of certain types in this system does tend
>> to produce certain consolidation pressures that we need to acknowledge, but

---

From: Eli-Shaoul Khedouri <[email-masked]>
Date: Tue, 14 Apr 2020 21:47:42 -0700

> Really? The motivating example seems like it is asserting that the holder

This is indeed one of the initial applications, and it does seem to make
sense to call out this point explicitly.

> designing a protocol as inflexible as you suggest.

Would also prefer to see more than 4 bits as an option. Different
applications will have different requirements, and understanding the
implications for the privacy budget is important. But zero bits of content
would make for a very limited set of applications.

We can even imagine this being chosen by the user in the captcha scenario,
with benefits accruing for accepting blinded tokens that contain enough
bits to let the validating service apply differential treatment, e.g. show
fewer challenges.

Eli

>>> >> (1) the problems and (2) the scope of our ambition to address them...
>>> >
>>> I would rather not scope as narrowly as “is human” as I think some of
>>> the proposed applications being considered are somewhat broader than that
>>> interactions, key rotations etc...) but going beyond that seems beyond the
>>> scope of the work, in my opinion..
>>>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 15 Apr 2020 14:15:43 -0400

> Really? The motivating example seems like it is asserting that the holder

It might assert that _someone_ has passed a CAPTCHA.  The verifier cannot
determine anything about the current holder, and doesn't need to.

I would phrase the goal as "enabling issuers to allocate quotas of an
arbitrary resource to authorized users, and allow those quotas to be used
anonymously".  In the CAPTCHA case, authorization means completing the
CAPTCHA, and the quota is a measure of serving costs (e.g. megabytes, page
loads).

>> I think we should rule all content (blind signing) strictly out of
>> scope.  The complexity of supporting content is not worth it for N<4 bits;
>> just encode the content in unary by the choice of issuer.  If that proves
>> too inefficient after this is all finished, we can consider a follow-on

In that case, we should mention an example of such an application in the
charter.  However, I would want to think carefully about whether the use
case retains enough anonymity that all this cryptography matters.

---

From: Chelsea Komlo <[email-masked]>
Date: Wed, 15 Apr 2020 20:48:06 -0600

> case retains enough anonymity that all this cryptography matters.

With every bit that is added, the growth in the number of anonymity sets
that a user can fall into grows exponentially. The protocol will need some
degree of inflexibility to ensure that users have strong guarantees against
tracking by issuers- a core purpose of Privacy Pass.

Putting hard bounds on the number of bits seems to be the most controllable
lever for ensuring a large anonymity set, as opposed to regulating the
number of issuers. Consequently, the number of bits should be kept low to
ensure the protocol's effectiveness to protect user privacy.

Chelsea