Re: [Secdispatch] Dispatching draft on key consistency

[Eric Rescorla <[e-mail]>]

On Fri, Mar 11, 2022 at 6:15 PM Christopher Wood <[e-mail]>
wrote:

>
>
> > 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.
>

Just to sharpen this point, there are uses of key consistency other than
for proxied protocols. For instance, consider the case where you want to
amortize the cost of solving a captcha. In this case, the server would
force the user to solve the captcha and then issue some number of signed
tokens (with some kind of VOPRF or something so that it didn't see the
actual token value) which can then be used to avoid the captcha the next
time. For obvious reasons, we'd like the same key to be used to compute the
VOPRF for each user.


> >
> >>> 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.
>

I think in the case I described above, you wouldn't use the token going
forward and maybe warn the user.

-Ekr


>
> Best,
> Chris
>
> >
> > --
> > Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting )
> >           Sandelman Software Works Inc, Ottawa and Worldwide
> >
> >
> >
> >
>
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>