Re: [Secdispatch] Dispatching draft on key consistency

[Christopher Wood <[e-mail]>]

Hi Michael,

Apologies for the delayed reply. Please see inline below.

> On Mar 5, 2022, at 11:03 AM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Christopher Wood <[e-mail]> wrote:
>> There are a number of different protocols that require multiple clients
>> to discover a common — or consistent — cryptographic public key for
>> use, including: Privacy Pass [1], Oblivious DoH [2], and Oblivious HTTP
>> [3]. Consistency here means that all clients obtain the same view of
>> the public key. An inconsistent view can lead to privacy attacks.
> 
>> For example, in Privacy Pass, if an attacker can somehow force a single
>> (set of) client(s) to use a public key that is distinct from all other
>> clients, then the key used effectively partitions the set of clients
>> into two buckets, and the size and number of these partitions influence
>> the overall privacy posture of the protocol.
> 
> "somehow" ... such an attacker can substitute any on-path attacker key.
> I don't see how this is distinct from all the other attacks.

The problem here is, say, forcing one single client to use key A and all other clients to use key B. The attacker would then be able to identify the individual client whenever key A is used.

> 
>> [4] https://datatracker.ietf.org/doc/draft-wood-key-consistency/
>> [5] https://datatracker.ietf.org/doc/slides-110-privacypass-key-consistency-and-discovery/
> 
> In reviewing the documents, it seems that it's not "somehow", it's that the proxy has been
> persuaded to collude with a third party.  Perhaps that would be better to say.

It’s not clear to me what you mean by "the proxy” here. The document doesn’t make any assumption about a proxy. Indeed, direct discovery a la section 4.1 (https://datatracker.ietf.org/doc/html/draft-wood-key-consistency-02#section-4.1) involves only client and server. Would you mind clarifying what you mean?

> Perhaps "persuaded" is the wrong term as well, since I think that the goal is
> to defend the proxy against NSLs that would force the proxy to collude.
> 
> What is needed is a kind of canary such that for clients can detect when they
> are being singled out, and then refuse to operate with that proxy.  By
> existence of such a mechanism, proxies can effectively render themselves
> useless to such forms of "persuasion".

The purpose of key consistency is to give clients a way to ensure they are not being singled out, not to tell clients when they are being singled out. These seem like different sides of the same coin, no?

Best,
Chris

> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide