Re: [Privacy-pass] Detecting malicious registries/servers

[Steven Valdez <[e-mail]>]

There at the very least needs to be an unlinkable transport between
issuer/verifier connections, since otherwise you have immediate linkability
there.

This may not be a hard requirement for communication with the registry, if
we have some sort of KT/CT approach where all the registries would need to
be colluding in order to provide a false view to specific clients. Though
it seems useful to still recommend that registry interactions happen on an
unlinkable transport in addition to any additional protections we might
have for split views/different keys.

On Tue, Aug 4, 2020 at 9:44 AM Ben Schwartz <[e-mail]> wrote:

> On Tue, Aug 4, 2020 at 9:21 AM Chelsea Komlo <[e-mail]> wrote:
>
>> Note the proposal I describe below **is not** intended to solve the
>> unlinkable transport problem. It is a mechanism to detect when malicious
>> registries/servers publish different keys to different users.
>>
> Do we have to assume an unlinkable transport anyway, in order for Privacy
> Pass to work at all?  (It seems like the answer may be yes, at least with
> respect to Verifiers.)
>
> If we have an unlinkable transport, can a malicious+colluding registry
> publish different keys to different users without generating a fatal
> mismatch?  (This might depend on the details of our unlinkability
> assumptions.)
>
> Are you proposing a layered-defense model, where we require unlinkable
> transport and also add defenses against a transport privacy break?
>
>> Clearly Privacy Pass shouldn't try to provide an unlinkable transport;
>> there are already existing tools for that, like Tor.
>> ------------------------------
>> *From:* Steven Valdez <[e-mail]>
>> *Sent:* Tuesday, August 4, 2020 1:07:00 AM
>> *To:* Chelsea Komlo
>> *Cc:* Ben Schwartz; Chelsea Komlo; [e-mail]
>> *Subject:* Re: [Privacy-pass] Detecting malicious registries/servers
>>
>> I don't think the Privacy Pass drafts can really solve the unlinkable
>> communication problem, and shouldn't focus on it besides listing it as a
>> requirement. Depending on the use case/caller, communicating with the
>> Issuer/Redeemer in an unlinkable way could involve making completely
>> disconnected TLS/HTTP connections, dropping all state (some sort of
>> anonymous mode), changing request patterns so they can't be time
>> correlated, etc.
>>
>> PrivacyPass can make the protocol robust against unlinkability based on
>> the contents of protocol messages, but solving unlinkability based on the
>> transport seems outside of the PrivacyPass scope, though listing the
>> requirements that would be maintained could be useful for use cases built
>> on top of Privacy Pass.
>>
>> On Mon, Aug 3, 2020 at 6:14 PM Chelsea Komlo <[e-mail]> wrote:
>>
>>> It seems there was a slight miscommunication with the point I was trying
>>> to make during the meeting, so I'll clarify.
>>>
>>>
>>> I am strongly in favor of making the protocol as robust as possible,
>>> while being transparent about what risks cannot be mitigated in certain
>>> settings (such as servers building a lookup table).
>>>
>>>
>>> Placing the burden on implementations to figure out how to ensure the
>>> primary use case of the protocol- unlinkability- is counterintuitive to me.
>>>
>>>
>>>
>>>
>>> ------------------------------
>>> *From:* Privacy-pass <[e-mail]> on behalf of Ben
>>> Schwartz <bemasc=[e-mail]>
>>> *Sent:* Monday, August 3, 2020 9:59:59 AM
>>> *To:* Chelsea Komlo
>>> *Cc:* [e-mail]
>>> *Subject:* Re: [Privacy-pass] Detecting malicious registries/servers
>>>
>>> I found your and Richard's comment during the meeting particularly
>>> insightful on this point: we should clarify the assumptions Privacy Pass
>>> has to make about the intrinsic identifiability of client requests.  For
>>> example, if Privacy Pass necessarily assumes that the Client's connections
>>> to Verifiers are unlinkable, then perhaps we can simply declare that the
>>> Client's connections to Registries must be similarly unlinkable.
>>>
>>> The mechanism for ensuring that unlinkability might be out of scope for
>>> us, but we would need to describe the requirements for it.
>>>
>>> On Mon, Aug 3, 2020 at 5:16 PM Chelsea Komlo <[e-mail]>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> One question that has been raised is how clients can detect registry or
>>>> server misbehavior. One particular concern is the possibility that
>>>> registries or servers can perform targeted attacks by publishing different
>>>> keys to specific users without detection (resulting in a small anonymity
>>>> set).
>>>>
>>>> While client-side gossip protocols or use of anonymity networks give
>>>> the client an option to detect such targeted attacks, these options are not
>>>> necessarily generalizable.
>>>>
>>>> However, I think if we introduce the assumption that *at least one*
>>>> registry is acting honestly, then this problem may be easier to solve.
>>>>
>>>> Registries just need to add an additional capability to query other
>>>> registries on behalf of a client (if the client specifies this in their
>>>> request). In doing so, they can act as a one-hop proxy for the client. If
>>>> clients perform these requests periodically through a series of
>>>> randomly-chosen registries, they should eventually be able to detect
>>>> misbehavior, assuming one of the registries is acting honestly.
>>>>
>>>> Chris Wood pointed out to me that the above approach may have false
>>>> positives when a server rotates their key, so adding some kind of
>>>> "suspected" and "failed state" with retries might help get around such edge
>>>> cases.
>>>>
>>>> Thanks,
>>>> Chelsea
>>>> --
>>>> 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
>>>
>>
>>
>> --
>>
>> Steven Valdez |  Chrome Privacy Sandbox |  [e-mail] |
>> 210-692-4742 <(210)%20692-4742>
>>
>

-- 

Steven Valdez |  Chrome Privacy Sandbox |  [e-mail] |
 210-692-4742