Consider ensuring end-to-end configuration authenticity

[sysrqb]

The client may not have a mechanism for verifying that a configuration is authentic - only consistent within the assumptions of the design. For Privacy Pass, the client already processes a cryptographic key from which it derives the keyid and the client trusts that its set of K-Check mirrors won't collude with the origin. A similar situation exists with other profiles, such as OHTTP.

One suggestion we received is requiring self-authenticating configurations.

[bemasc]

Specifically, K-Check appears to weaken the security of OHTTP. Normally, OHTTP guarantees authenticity and privacy as long as at least one of the proxy or the gateway is well-behaved. With K-Check, authenticity and privacy can fail even if the gateway is well-behaved, if the K-Check mirrors collude to impersonate the gateway.

EDIT: I think the most practical solution to this is to simply note the problem and recommend that K-Check only be used with self-authenticating resources. A more aggressive solution would be to specify JSON Web Signature or HTTP Signed Exchange as the supported resource type.

[sysrqb]

I think there is an unstated assumption somewhere in here. Can you help clarify?

I agree with the privacy and authenticity guarantees you described, without using K-Check, as long as the relay and gateway don't collude and at least one of them is well-behaved. The underlying assumption here is that the client was pre-configured with the gateway's key configuration and that configuration was consistent with all other clients of this service (eliding the need for K-Check, in this case).

In the case where the client must check the consistency of the configuration it has, then we can still assume the client was pre-configured with that configuration. If the client has multiple K-Check servers configured, then if a majority of those servers collude, then they can persuade the client that the pre-configured configuration is not consistent. This would cause a DoS, but not reduce the guarantees of the service.

Were you thinking of different assumptions? Maybe the client isn't pre-configured with the key configuration and it must fetch (or update) its cache?

[bemasc]

The underlying assumption here is that the client was pre-configured with the gateway's key configuration

To be precise, I'm imagining "normal OHTTP" to work by pre-configuring the client with a URL for the gateway's key configuration, which the client fetches over an authenticated transport (i.e. "direct discovery"). As written, the K-Check document seems to replace this step, by fetching via the mirror pool. If the intention is instead to augment the authenticated fetch, the document should say so. However, that would be very similar to DoubleCheck, and raises some of the same issues:

1. Direct discovery (without a transport proxy with a suitable trust model) reveals the client IP addresses to the gateway. While this doesn't directly break the unlinkability guarantees, it creates a significant weakness when joined with external behavioral profiles (see also #15), and a near-total break if timing correlations are present (i.e., config fetch immediately precedes config use, see #14).
2. Direct discovery exacerbates the Thundering Herd problem when the target resource changes.

[chris-wood]

As written, the K-Check document seems to replace this step, by fetching via the mirror pool.

This isn't the case. K-Check complements this check. It assumes that the input key material was obtained in some authoritative fashion (thereby knowing that it's "correct"), and its purpose is to check that this is the same key shared by others (checking if it's "consistent").

[bemasc]

OK, thanks for the explanation. For this issue, I think it would be sufficient to clarify that in the document.

As noted in #16, I'm not sure it's always a good idea to draw a total abstraction boundary between correctness and consistency. If the correctness validation procedure (or subsequent use) relies on a privacy proxy, then the K-Check procedure can safely be simplified to K=1, with improved privacy.

[chris-wood]

As noted in https://github.com/chris-wood/draft-group-privacypass-k-check/issues/16, I'm not sure it's always a good idea to draw a total abstraction boundary between correctness and consistency. If the correctness validation procedure (or subsequent use) relies on a privacy proxy, then the K-Check procedure can safely be simplified to K=1, with improved privacy.

It doesn't necessarily rely on a privacy proxy, which is why the separation exists. As an example, clients do not necessarily need to hide their IP address from an OHTTP gateway if they fetch the config directly from it. The whole point of the consistency check is to ensure that their config is, well, consistent with every other client (using the same set of mirrors), regardless of how they happened to obtain the authenticated copy.

[bemasc]

I'm totally OK with defining K-Check (or perhaps the Mirror Protocol) as a limited-purpose component that is separate from authentication and usage of the resource. Currently, the draft is not clear on that point; I came away with the impression that K-Check was also being used for authentication (which it does provide under certain, slightly worrying security assumptions).

I do think that usage of K-Check is actually not as independent from the protocol as the current text implies, but that's a topic for a different issue.

[chris-wood]

@sysrqb do we want to keep this open? I think self-certifying configurations are somewhat orthogonal to the core work here.

[chris-wood]

I'm going to close this as resolved, since resources can be self-certifying on top of the mirror protocol without requiring any changes. Please feel free to re-open as needed.