Re: [Secdispatch] Dispatching draft on key consistency

[Christopher Wood <[e-mail]>]

> On Mar 11, 2022, at 3:40 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Christopher Wood <[e-mail]> wrote:
>>> "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.
> 
> I understand.
> 
>>>> [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?
> 
> Oblivious DoH and Oblivious HTTP involve some kind of intermediary.
> Maybe calling it a proxy is incorrect, but there is a third party.

I think there’s still a misunderstanding here. This draft discusses key consistency that can be _used_ by things like ODoH and OHTTP since, at the end of the day, key consistency is a separable problem. In other words, the draft doesn’t assume any particular protocol in which the key material is used, though the choice of consistency mechanism one uses may certainly be influenced by the protocol for which consistency is required.

> 
>>> 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?
> 
> Hard to prove a negative.
> Easier to give them a way to recognize a positive, I think.

Hmm… I’m not sure I’m following you. Ensuring consistency is proving a positive, i.e., that all clients share the same view of the keying material. (It’s possible we’re saying the same thing but with different words.)

> Either way, what does the client do when it figures out it has been singled out?

That’s up to the client to decide, I think. It could choose to not use the key for the corresponding protocol, raise some alarms, or whatever else makes sense for the given application.

> If the goal is to hide in the crowd,  then if there is a spotlight on you,
> better act "normally" right, and not give away that one has figure out one
> has been found out?
> 
> The client probably needs to go ahead and pretend it hasn't been singled out,
> and do some innoculous transactions anyway, right?

As above, what the client does when it cannot guarantee consistency is a detail left to the relevant application. That said, I think you’re right in that the client’s behavior — reactive or not — should not lend itself to further privacy problems. 

Best,
Chris

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