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

[Chelsea Komlo <[e-mail]>]

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