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

From: Chelsea Komlo <[email-masked]>
Date: Mon, 3 Aug 2020 15:15:45 -0600

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

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 3 Aug 2020 17:59:59 -0400

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 <[email-masked]>
wrote:

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

---

From: Chelsea Komlo <[email-masked]>
Date: Mon, 3 Aug 2020 22:14:05 +0000

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 <[email-masked]> on behalf of Ben Schwartz <bemasc=[email-masked]>
Sent: Monday, August 3, 2020 9:59:59 AM
To: Chelsea Komlo
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/privacy-pass

---

From: Steven Valdez <[email-masked]>
Date: Tue, 4 Aug 2020 09:07:00 -0400

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 <[email-masked]> 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 <[email-masked]> on behalf of Ben
> Schwartz <bemasc=[email-masked]>
> *Sent:* Monday, August 3, 2020 9:59:59 AM
> *To:* Chelsea Komlo
> *Cc:* [email-masked]
> *Subject:* Re: [Privacy-pass] Detecting malicious registries/servers
>
> The mechanism for ensuring that unlinkability might be out of scope for
> us, but we would need to describe the requirements for it.
>

-- 

Steven Valdez |  Chrome Privacy Sandbox |  [email-masked] |
 210-692-4742

---

From: Chelsea Komlo <[email-masked]>
Date: Tue, 4 Aug 2020 13:21:31 +0000

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.

Clearly Privacy Pass shouldn't try to provide an unlinkable transport; there are already existing tools for that, like Tor.

________________________________
From: Steven Valdez <[email-masked]>
Sent: Tuesday, August 4, 2020 1:07:00 AM
To: Chelsea Komlo
Cc: Ben Schwartz; Chelsea Komlo; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

________________________________
From: Privacy-pass <[email-masked]<mailto:[email-masked]>> on behalf of Ben Schwartz <bemasc=[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 3, 2020 9:59:59 AM
To: Chelsea Komlo
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Privacy-pass] Detecting malicious registries/servers

Thanks,
Chelsea

--

Steven Valdez |  Chrome Privacy Sandbox |        [email-masked]<mailto:[email-masked]> |         210-692-4742

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 4 Aug 2020 09:44:37 -0400

On Tue, Aug 4, 2020 at 9:21 AM Chelsea Komlo <[email-masked]> 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 <[email-masked]>
> *Sent:* Tuesday, August 4, 2020 1:07:00 AM
> *To:* Chelsea Komlo
> *Cc:* Ben Schwartz; Chelsea Komlo; [email-masked]
> PrivacyPass can make the protocol robust against unlinkability based on
> the contents of protocol messages, but solving unlinkability based on the
>> 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).
>>
>>
> 210-692-4742 <(210)%20692-4742>
>

---

From: Steven Valdez <[email-masked]>
Date: Tue, 4 Aug 2020 09:53:57 -0400

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 <[email-masked]> wrote:

>>>> While client-side gossip protocols or use of anonymity networks give
>>>> the client an option to detect such targeted attacks, these options are not

--

---

From: Chelsea Komlo <[email-masked]>
Date: Tue, 4 Aug 2020 14:18:58 +0000

It is fair to recommend use of an unlinkable transport, as this ensures building a lookup table for tokens/IP addresses will not result in useful information to the verifier. This transport could be as strong as Tor or as weak as a VPN/proxy [1].

The scenario I described below--where a malicious registry/issuer publishes different keys to different users to create a smaller anonymity set--is completely independent to the transport used. Clients need some mechanism to verify the keys they are given are the same as all other clients, as this ensures their tokens are cryptographically indistinguishable to the verifier.

[1] https://github.com/bslassey/ip-blindness

________________________________
From: Steven Valdez <[email-masked]>
Sent: Tuesday, August 4, 2020 1:53:57 AM
To: Ben Schwartz
Cc: Chelsea Komlo; Chelsea Komlo; [email-masked]
Subject: Re: [Privacy-pass] Detecting malicious registries/servers

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 <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Aug 4, 2020 at 9:21 AM Chelsea Komlo <[email-masked]<mailto:[email-masked]>> wrote:

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?

________________________________
From: Steven Valdez <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, August 4, 2020 1:07:00 AM
To: Chelsea Komlo
Cc: Ben Schwartz; Chelsea Komlo; [email-masked]<mailto:[email-masked]>
Subject: Re: [Privacy-pass] Detecting malicious registries/servers

Thanks,
Chelsea

--

Steven Valdez |  Chrome Privacy Sandbox |        [email-masked]<mailto:[email-masked]> |         210-692-4742<tel:(210)%20692-4742>

--

---

From: Alex Davidson <[email-masked]>
Date: Mon, 10 Aug 2020 17:41:16 +0100

Hi all,

I think this proposal makes sense as a general framework that we can recommend for auditing a server's key material. We’re currently (& deliberately) quite vague about how registries operate and do not define anything about how they interoperate, but I could see this recommendation added to the architecture doc as part of a general set of recommendations for auditing server misbehaviour. 

For instance, in Section 4 we could add a new subsection that covers auditing procedures for key material in registries, and describe this mechanism as a potential way of doing that. We could then update Section 7.3 to refer to this advice when describing potential methods for checking that the server is not fragmenting its key material for different clients. Would this make sense? 

Note, if we wanted to be more specific about this recommendation (or anything else) then we would probably have to go into more detail on the construction of the key management ecosystem itself. My opinion is that specifying the key management framework beyond what we currently have is beyond the scope of the WG, and thus something that we probably want to avoid. But I’m happy to hear differing opinions on this.

Thanks,
Alex

> On 4 Aug 2020, at 15:18, Chelsea Komlo <[email-masked]> wrote:
> 
> [1] https://github.com/bslassey/ip-blindness <https://github.com/bslassey/ip-blindness>
> On Tue, Aug 4, 2020 at 9:44 AM Ben Schwartz <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, Aug 4, 2020 at 9:21 AM Chelsea Komlo <[email-masked] <mailto:[email-masked]>> wrote:
> From: Steven Valdez <[email-masked] <mailto:[email-masked]>>
> Cc: Ben Schwartz; Chelsea Komlo; [email-masked] <mailto:privacy-pass@ietf..org>
> On Mon, Aug 3, 2020 at 6:14 PM Chelsea Komlo <[email-masked] <mailto:[email-masked]>> wrote:
> From: Privacy-pass <[email-masked] <mailto:[email-masked]>> on behalf of Ben Schwartz <bemasc=[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On Mon, Aug 3, 2020 at 5:16 PM Chelsea Komlo <[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/privacy-pass <https://www.ietf.org/mailman/listinfo/privacy-pass>
> -- 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/privacy-pass <https://www.ietf.org/mailman/listinfo/privacy-pass>
> 
> 
> -- 
> 
> Steven Valdez |	 Chrome Privacy Sandbox |	 [email-masked] <mailto:[email-masked]> |	 210-692-4742 <tel:(210)%20692-4742>
> 
> -- 
> 
> Steven Valdez |	 Chrome Privacy Sandbox |	 [email-masked] <mailto:[email-masked]> |	 210-692-4742
> --

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 10 Aug 2020 14:12:36 -0400

On Mon, Aug 10, 2020 at 12:41 PM Alex Davidson <[email-masked]>
wrote:

> Hi all,
>
> I think this proposal makes sense as a general framework that we can
> recommend for auditing a server's key material. We’re currently (&
> deliberately) quite vague about how registries operate and do not define
> anything about how they interoperate, but I could see this recommendation
> added to the architecture doc as part of a general set of recommendations
> for auditing server misbehaviour.
>
> For instance, in Section 4 we could add a new subsection that covers
> auditing procedures for key material in registries, and describe this
> mechanism as a potential way of doing that. We could then update Section
> 7.3 to refer to this advice when describing potential methods for checking
> that the server is not fragmenting its key material for different clients.
> Would this make sense?
>

Wherever you put it, I would suggest combining this with Section 3.2.1,
since they appear to address the same problem.  In general, I would
appreciate more thought on the transport linkability requirements,
especially if we require some "non-collusion" assumptions (as seems
inevitable).

Note, if we wanted to be more specific about this recommendation (or
> anything else) then we would probably have to go into more detail on the
> construction of the key management ecosystem itself. My opinion is that
> specifying the key management framework beyond what we currently have is
> beyond the scope of the WG, and thus something that we probably want to
> avoid. But I’m happy to hear differing opinions on this.
>
> Thanks,
> Alex
>
> It is fair to recommend use of an unlinkable transport, as this ensures
> building a lookup table for tokens/IP addresses will not result in useful
> information to the verifier. This transport could be as strong as Tor or as
> weak as a VPN/proxy [1].
>
> The scenario I described below--where a malicious
> registry/issuer publishes different keys to different users to create a
> smaller anonymity set--is completely independent to the transport
> used. Clients need some mechanism to verify the keys they are given are the
> same as all other clients, as this ensures their tokens are
> cryptographically indistinguishable to the verifier.
>
> *Sent:* Tuesday, August 4, 2020 1:53:57 AM
> *To:* Ben Schwartz
> *Cc:* Chelsea Komlo; Chelsea Komlo; [email-masked]
>>> <privacy-pass@ietf..org>
>>>> It seems there was a slight miscommunication with the point I was
>>>> trying to make during the meeting, so I'll clarify.
>>>>
>>>>> One question that has been raised is how clients can detect registry
>>>>> or server misbehavior. One particular concern is the possibility that

---

From: Chelsea Komlo <[email-masked]>
Date: Thu, 27 Aug 2020 04:05:40 +0000

Hi Alex,

Sorry for the delay. Sure, I think your proposal will be helpful; overall giving some information in the draft on 1) what bad things would happen if clients did not have an auditing mechanism, and 2) possible auditing procedures that implementation can take.

Let me know if you want me to review this once you've added it to the draft.

________________________________
From: Alex Davidson <[email-masked]>
Sent: Monday, August 10, 2020 4:41:16 AM
To: Chelsea Komlo
Cc: Steven Valdez; Ben Schwartz; Chelsea Komlo; [email-masked]
Subject: Re: [Privacy-pass] Detecting malicious registries/servers

Hi all,

Thanks,
Alex

On 4 Aug 2020, at 15:18, Chelsea Komlo <[email-masked]<mailto:[email-masked]>> wrote:

Cc: Chelsea Komlo; Chelsea Komlo; [email-masked]<mailto:[email-masked]>

Cc: Ben Schwartz; Chelsea Komlo; [email-masked]<mailto:privacy-pass@ietf..org>

Thanks,
Chelsea

--

--