Re: [Privacy-pass] Draft on key consistency and discovery

[Matthew Finkel <[e-mail]>]

On Thu, Feb 25, 2021 at 12:01:10PM -0500, Ben Schwartz wrote:
> Thanks!  Some notes:

Thanks!

> 
> >    Privacy-focused protocols which rely on widely shared public keys
> >   typically require keys be consistent and correct.
> 
> Is TLS not a privacy-focused protocol?  I guess not by this definition.  A
> "terms" section could help.

An easy answer is substituting "Privacy-" with "Anonymity-" or
"Pseudonymity-". Alternatively, it can simply say "Some protocols", and
remove "typically".

> 
> >   *  Presenting a signed assertion from a trusted entity that the key
> >      is correct.
> 
> Do you mean "the key is universal/consistent"?
> 

Defining these in the terminology section may be beneficial. I hesitate
calling it "universal" simply because we need to allow key rotation with
an overlap period, and in that case there may exist more than one
correct public key.

Given that an assertion only implies what the trusted entity "knew" at
the time it created the assertion, I think correctness/validity are the
only two properties we can claim. The assertion can claim "universality"
(the trusted entity didn't know about any other keys associated with a
domain name at the time of signing), but that is only useful when a
client trusts only one entity, or if there is some (log-based)
transparency mechanism available on top of this.

> >   *  Presenting proof that the key is present in some tamper-proof log,
> >      similar to Certificate Transparency ([RFC6962]) logs.
> 
> Do you mean that the log would apply some policy to prevent large numbers
> of keys (prevention)?  Or that an external auditor could use the log to
> accuse the server of a policy violation (deterrence)?
> 

Both seem necessary.

> >   *  The proxy can give all users a key owned by the proxy, and either
> >      collude with the server to use this key or retroactively use this
> >      key to compromise user privacy when users later make use of the
> >      key.
> 
> The latter vulnerability seems easily avoided, no?  If the server has a
> domain name, for example, it can easily sign its current "universal key"
> with a public key that is tied to the name (e.g. a DV X.509 certificate).

Yes, that's one option, if you include the entire cert chain for the
server along with the public key (and then this sounds like delegated
credentials).

> 
> For Privacy Pass, at least, there is potentially a presumption that the
> user has access to the network in a way that hides their identity and does
> not collude with the target.  This might mean that the user's DNS resolver
> is presumed to be trusted.  In that model, the resolver could act like a
> trusted proxy (Section 4.2).

Yes, but that could be misleading. "One DNS resolver" does not
necessarily translate into one DNS cache, especially not a global DNS
cache, so the global consistency properties of DNS are a bit fuzzy.

> 
> On Mon, Feb 22, 2021 at 6:13 PM Christopher Wood <[e-mail]>
> wrote:
> 
> > A few of us put together a draft describing various requirements and
> > possible solutions for key consistency and discovery:
> >
> >    https://datatracker.ietf.org/doc/draft-wood-key-consistency/
> >
> > The result be of interest to folks in this WG. If there is room on the
> > agenda for a discussion around this topic, especially as it pertains to
> > Privacy Pass, I would be happy to present it during the upcoming IETF 110
> > meeting.
> >
> > Best,
> > Chris
> >
> > --
> > Privacy-pass mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/privacy-pass
> >



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