Key Consistency for Oblivious HTTP by Double-Checking

4.1. Oblivious Request Resource

The Oblivious Request Resource MUST publish an Access Description [I-D.schwartz-masque-access-descriptions] over HTTP/3 containing the ohttp.request key, e.g.:¶

{
  "ohttp": {
    "request": {
      "uri": "https://example.com/ohttp/",
      "key": "(KeyConfig in Base64)"
    }
  }
}

The Oblivious Request Resource MUST include a "strong validator" ETag (Section 2 of [RFC7232]) in any response to a GET request for this access description, and MUST support the "If-Match" HTTP request header (Section 3 of [RFC7232]). The response MUST indicate "Cache-Control: public, no-transform, s-maxage=(...), immutable" [I-D.ietf-httpbis-cache][RFC8246]. For efficiency reasons, the max age SHOULD be at least 60 seconds, and preferably much longer.¶

If this Access Description changes, and the resource receives a request whose "If-Match" header identifies a previously served version that has not yet expired, it MUST return a success response containing the previous version. This response MAY indicate "Cache-Control: private".¶

4.2. Oblivious Proxy

The Oblivious Proxy MUST publish an Access Description that includes the ohttp.proxy and udp keys, indicating support for CONNECT-UDP [I-D.ietf-masque-connect-udp]. It SHOULD also contain the dns key, indicating support for DNS over HTTPS [RFC8484], to enable the use of HTTPS records with CONNECT-UDP.¶

{
  "dns": {
    "template": "https://doh.example.com/dns-query{?dns}",
  },
  "udp": {
    "template":
        "https://proxy.example.org/masque{?target_host,target_port}"
  },
  "ohttp": {
    "proxy": {
      "template": "https://proxy.example.org/ohttp{?request_uri}"
    }
  }
}

The Oblivious Proxy Resources MUST allow use of the GET method to retrieve small JSON responses, and SHOULD make ample cache space available in order to cache Access Descriptions. Each proxy instance (as defined by its external-facing network interface) MUST share cache state among all clients to ensure that they use the same Access Descriptions for each Oblivious Request Resource.¶

Oblivious Proxies MUST preserve the ETag response header on cached responses, and MUST add an Age header ([I-D.ietf-httpbis-cache-19], Section 5.1) to all proxied responses. Oblivious Proxies MUST respect the "Cache-Control: immutable" directive, never revalidating these cached entries, and MUST NOT accept PUSH_PROMISE frames from the target.¶

Proxies SHOULD employ defenses against malicious attempts to fill the cache. Some possible defenses include:¶

• Rate-limiting each client's use of GET requests.¶
• Prioritizing preservation of cache entries that have been served to many clients, if eviction is required.¶

Oblivious Proxies that are not intended for general-purpose proxy usage MAY impose strict transfer limits or rate limits on HTTP CONNECT and CONNECT-UDP usage.¶

4.3. Client

The Client is assumed to know an "https" URI of an Oblivious Request Resource's Access Description. To use that Request Resource, it MUST perform the following "double-check" procedure:¶

1. Send a GET request to the Oblivious Proxy's template with request_uri set to the Access Description URI.¶
2. Record the response (A).¶
3. Check that response A's "Cache-Control" values indicates "public" and "immutable".¶
4. Fetch the Access Description URI from its origin via CONNECT-UDP, with "If-Match" set to response A's ETag.¶
5. Record the response (B).¶
6. Check that responses A and B were successful and the contents are identical, otherwise fail.¶

This procedure ensures that the Access Description is authentic and will be shared by all users of this proxy. Once response A or B expires, the client MUST refresh it before continuing to use this Access Description, and MUST repeat the "double-check" process if either response changes.¶

6.1. In scope

A malicious proxy could attempt to learn the contents of the oblivious request by forging an Access Description containing its own KeyConfig. This is prevented by the client's requirement that the KeyConfig be served to it by the configured origin over HTTPS (Section 4.3).¶

A malicious target could attempt to link multiple requests together by issuing each user a unique, persistent KeyConfig. This attack is prevented by the client's requirement that the KeyConfig be fresh according to the proxy's cache (Section 4.3).¶

A malicious target could attempt to rotate its entry in the proxy's cache in several ways:¶

• Using HTTP PUSH_PROMISE frames. This attack is prevented by disabling PUSH_PROMISE at the proxy (Section 4.2).¶

• By also acting as a client and sending requests designed to replace the Access Description in the cache before it expires:¶

  • By sending requests with a "Cache-Control: no-cache" or similar directive. This is prevented by the response's "Cache-Control: public, immutable" directives, which are verified by the client (Section 4.3).¶
  • By filling the cache with new entries, causing its previous Access Description to be evicted. Section 4.2 describes some possible mitigations.¶

A malicious client could use the proxy to send abusive traffic to any destination on the internet. Abuse concerns can be mitigated by imposing a rate limit at the proxy (Section 4.2).¶

6.2. Out of scope

This specification assumes that the client starts with identities of the proxy and target that are authentic and widely shared. If these identities are inauthentic, or are unique to the user, then the security goals of this specification are not achieved.¶

This specification assumes that at most a small fraction of clients are acting on behalf of a malicious target. If a large fraction of the clients are malicious, they could conspire to flood the proxy cache with entries that seem popular, leading to rapid eviction of the malicious target's Access Descriptions. Similar concerns apply if a malicious target can compel naive clients to fetch a very large number of Access Descriptions.¶