[ODoH] Client bootstrapping concerns. How should client obtain T's SVCB/HTTPS records?

[dmcardle]

Is it fair to say the goal is that the attacker cannot link clients to corresponding (query, answer) pairs, even when one of proxy P or target T is compromised?

Given that goal, let's do a case analysis to determine how the client should obtain T's SVCB/HTTPS records.

Case 1: client queries target T for T's SVCB/HTTPS records.

If target T is compromised, it could serve a unique public key to each client and record the client's IP address. When T receives proxied queries from P, it can quickly recover the client's original IP address based on ObliviousDoHMessage.key_id. The attacker achieved linkability.

Case 2: client queries proxy P for T's SVCB/HTTPS records.

If proxy P is compromised, it could generate its own HPKE keypair(s) and serve the public key to the client. The client would dutifully encrypt queries for the attacker, who can trivially decrypt them. Since P can directly observe the client's IP address, the attacker has achieved linkability.

Case 3: client queries a third-party resolver (neither P nor T) for T's SVCB/HTTPS records.

I think this is what we'd want the client to do, as it's the only case that requires multiple parties to be compromised (or collusion).

FYI @ericorth @davidben

[bemasc]

Are you assuming a non-DNSSEC-validating stub resolver?

[dmcardle]

If the attacker has access to the compromised host's private key material, it could just forge new DNSSEC-validating records, right?

This is one of the assumptions made in the Security Considerations section.

Once compromised, the attacker has access to all session information and private key material.

[chris-wood]

If the attacker has access to the compromised host's private key material, it could just forge new DNSSEC-validating records, right?

If that includes the DNSSEC private keys, then yeah, that seems right. I think the text you quoted from the considerations is more about the TLS keying material.

Anyway, to the main comment (and thanks for reading and filing an issue!), I think something along the lines of (2) or (3) is a reasonable deployment story for applications that aren't willing to fetch the configs from DNS. (There are reasonable concerns with the DNSSEC requirement as-is.) I really don't want to impose any sort of transparency requirements on the system.

We certainly need to nail down the key management and discovery story here. :-)

[dmcardle]

I think something along the lines of (2) or (3) is a reasonable deployment story for applications that aren't willing to fetch the configs from DNS

I think we're on the same page now. Could you clarify the part about applications that aren't willing to fetch configs from DNS? I was imagining this bootstrapping step is just a DoH query to some resolver: P, T, or other.

Upon further thought, the problem I described in case 2 (bootstrapping from P) does rely on a non-DNSSEC-validating stub resolver. If only P is compromised, the attacker cannot forge T-signed records.

But I believe case 1 (bootstrapping from T) remains a bad idea because a compromised T can forge/sign records for itself, if we believe the DNSSEC private keys are compromised as well.

[chris-wood]

Could you clarify the part about applications that aren't willing to fetch configs from DNS? I was imagining this bootstrapping step is just a DoH query to some resolver: P, T, or other.

Sorry, I was referring to case (1) here, wherein the the client knows the target it wants to use and, as you say, just sends a DoH query directly to it.

[ericorth]

I agree case (1) seems very problematic for key retrieval. As you say, not a whole lot to stop T from issuing a key unique to the client IP, thus breaking the primary intended privacy protections of ODoH.

But a related topic that I've been thinking about lately (apologies if this is sidetracking the conversation too far): Is a direct query to T for its key useful purely as a validation step? Say you have a non-DNSSEC-validating stub. Would it be reasonable for that stub to use case (2) or (3) to retrieve an unvalidated key and then validate it by using case (1) and ensuring the key matches that received from (2) or (3)? Assuming a sufficiently high amount of usage and caching through P or Other, it seems it would be impractical for T to then assign a unique key to the client. It would have to be something usable by everybody else getting the key from P or Other. Then it seems the only extra information T would acquire is the knowledge that the client is potentially one of its clients, but T would not know which specific Oblivious queries were coming from that client.

[chris-wood]

I agree case (1) seems very problematic for key retrieval. As you say, not a whole lot to stop T from issuing a key unique to the client IP, thus breaking the primary intended privacy protections of ODoH.

This isn't quite right. Note that all this does is reveal the IP to the resolver for the purposes of retrieving a key. The "primary intended privacy protections" of ODoH are to break query<->client linkability which occurs after the key has been fetched. Hiding which clients are interested in using the target is not (yet) an explicit goal. If it were, I'd agree that (1) is probably not what we want.

Whether or not revealing the IP to the resolver during bootstrapping is desirable is obviously up to clients to decide, but I think it's important to note the distinction here. (The sort of "validation" step you propose would require this retrieval.)

In any case, something beyond (1) will likely be needed.

[ericorth]

But if the client goes directly to the target (and only to the target) for the key and the target gives a client-unique key, then the query<->client linkability could be discovered. The target then just has to record a client<->key mapping and knows which client is being dealt with for each key seen in queries.

As opposed to the validation idea above where the key is also retrieved from another party. If that successfully forces a non-unique key, then I think it is true that the target only discovers clients likely to be using the target but probably not which queries that client is making.

[chris-wood]

But if the client goes directly to the target (and only to the target) for the key and the target gives a client-unique key, then the query<->client linkability could be discovered.

Sure, but given caching, non-zero TTLs, and DNSSEC, this type of tagging is probably non trivial. (Privacy Pass also has this annoying problem, but they opted to solve the problem differently.) I think the system should allow clients to implement any of the variants above. And I think it does now, but certainly more work is needed here!

[ericorth]

I don't see how caching, non-zero TTLs, or DNSSEC help in any way when you're talking about a DoH connection directly between the stub and the DoH server intended as the Oblivious target as is the case for case (1). There's nothing between the two parties to cache anything and the target is the legitimate controller of the DNSSEC private keys.

Now if you're talking keys retrieved indirectly from a third party (either the proxy or a separate DNS server) as is the case for cases (2) and (3), then yes, I agree that those factors would make tagging impractical for the common well-used-resolver case.

[chris-wood]

target is the legitimate controller of the DNSSEC private keys.

I think this is where we may diverge, but nevertheless, this all seems very much deployment, configuration, etc specific.

[tfpauly]

In general, I agree that (3) is the right model. We need to have the keys available in some public, shared location that isn't directly part of the datapath for the proxy or the target.

[chris-wood]

The DNS-based discovery mechanism is no longer in this document, so I think we can close this.