Re: [Privacy-pass] Questions on client trust

[Eli-Shaoul Khedouri <[e-mail]>]

On Tue, Apr 14, 2020 at 9:09 PM Eric Rescorla <[e-mail]> wrote:

> On Tue, Apr 14, 2020 at 8:53 PM Ben Schwartz <bemasc=
> [e-mail]> wrote:
>
>> 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.
>>
>
> Really? The motivating example seems like it is asserting that the holder
> has passed some CAPTCHA.
>

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


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

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



> -Ekr
>
>
>> On Tue, Apr 14, 2020 at 7:50 AM Alex Davidson <adavidson=
>> [e-mail] <[e-mail]>>
>> wrote:
>>
>>>
>>> > On 14 Apr 2020, at 03:43, Martin Thomson <[e-mail]> wrote:
>>> >
>>> > On Tue, Apr 7, 2020, at 04:57, Ben Schwartz wrote:
>>> >> On Thu, Apr 2, 2020 at 6:44 AM Alex Davidson
>>> >> <adavidson=[e-mail]> wrote:
>>> >>> - 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...
>>> >
>>> > 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.
>>>
>>> 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..
>>>
>>> >> 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.
>>> >
>>> > 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
>>>
>>> --
>>> Privacy-pass mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>>
>> --
>> Privacy-pass mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>
> --
> Privacy-pass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>