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

From: "Christopher Wood" <[email-masked]>
Date: Mon, 22 Feb 2021 15:12:56 -0800

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

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 25 Feb 2021 12:01:10 -0500

Thanks!  Some notes:

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

>   *  Presenting a signed assertion from a trusted entity that the key
>      is correct.

Do you mean "the key is universal/consistent"?

>   *  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)?

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

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

On Mon, Feb 22, 2021 at 6:13 PM Christopher Wood <[email-masked]>
wrote:

> A few of us put together a draft describing various requirements and
> possible solutions for key consistency and discovery:
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>

---

From: Matthew Finkel <[email-masked]>
Date: Thu, 25 Feb 2021 23:39:42 +0000

> Thanks!  Some notes:

Thanks!

> "terms" section could help.

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

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

> accuse the server of a policy violation (deterrence)?

Both seem necessary.

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

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

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 26 Feb 2021 15:27:56 -0500

> cache, so the global consistency properties of DNS are a bit fuzzy.

Yes.  On the other hand, an adversary can probably identify which resolver
cache instance you're hitting by putting a different IP in each one, so
privacy beyond that level may be an illusion.

---

From: Eli-Shaoul Khedouri <[email-masked]>
Date: Fri, 26 Feb 2021 13:19:29 -0800

> privacy beyond that level may be an illusion.

This can be detected and mitigated by the client with TACK
<http://tack.io/draft.html>-style pinning pools, but seems a bit out of
scope for the core protocol.

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 26 Feb 2021 16:46:41 -0500

On Fri, Feb 26, 2021 at 4:19 PM Eli-Shaoul Khedouri <eli=
[email-masked]> wrote:

>> Yes.  On the other hand, an adversary can probably identify which
>> resolver cache instance you're hitting by putting a different IP in each
>> one, so privacy beyond that level may be an illusion.
>>
>

I'm not familiar with TACK.  Are you suggesting that the domain would
commit to the universality of its IP addresses and other DNS records?
That's an interesting idea, though it might not be compatible with using
classic DNS for connection setup.