Re: [Privacy-pass] Questions on client trust

[Ben Schwartz <[e-mail]>]

On Thu, Apr 2, 2020 at 6:44 AM Alex Davidson <adavidson=
[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?
>

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.

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

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.

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 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
> 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
>
> --
> Privacy-pass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>