Checking Resource Consistency with HTTP Mirrors

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 11 April 2024.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Privacy-enhancing protocols such as Privacy Pass [PRIVACYPASS] and Oblivious HTTP [OHTTP] require clients to obtain and use a public key for execution. In Privacy Pass, public keys are used by clients when issuing and redeeming tokens for anonymous authorization. In Oblivious HTTP (OHTTP), clients use public keys to encrypt messages to a gateway server.¶

Deployments of protocols such as Privacy Pass and OHTTP requires that very large sets of clients share the same key, or even that all clients globally share the same key. This is because the privacy properties depend on the client anonymity set size. In other words, the key that's used determines the set to which a particular client belongs. Using a unique, client-specific key would yield an anonymity set of size one, therefore violating the desired privacy goals of the system. Clients that use the same key as one another are said to have a consistent view of the key.¶

[CONSISTENCY] describes this notion of consistency in more detail. It also outlines several designs that can be used as the basis for consistency systems. This document is a concrete instantiation of one of those designs, "Shared Cache Discovery". In particular, this document describes the mirror protocol, which is a protocol for fetching a cached copy of an HTTP resource from so-called mirrors. In this context, a mirror is an HTTP resource that fetches and caches copies of other HTTP resources that can be returned to clients. In turn, clients can then use these cached resource copies for consistency checks, i.e., to compare their expected representation of the resource against that which the mirrors provide.¶

The mirror protocol can be run one or more times by an application to achieve the desired consistency criteria. For example, the mirror protocol can be run once with a trusted mirror, or more than once with many, potentially less trusted mirrors, and used for determining consistency. Section 5 provides general guidance for using the mirror protocol for consistency checks, along with specific profiles of the protocol for Privacy Pass and OHTTP in Section 5.3 and Section 5.4, respectively.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology

The following terms are used throughout this document:¶

• Resource: A HTTP resource identified by a URL.¶

• Normalized resource representation: A unique or otherwise protocol-specific representation that is derived from an HTTP resource. The process of normalization is specific to a protocol and the resource in question.¶

• Mirror: A HTTP resource that fetches and caches HTTP resources.¶

4. Mirror Protocol

The mirror protocol is a simple HTTP-based protocol similar to a reverse proxy. Each mirror resource, henceforth referred to as a mirror, is identified by a Mirror URI Template [RFC6570]. The scheme for the Mirror URI Template MUST be "https". The Mirror URI Template uses the Level 3 encoding defined Section 1.2 of [RFC6570] and contains one variables: "target", which is the percent-encoded URL of a HTTP resource to be mirrored. Example Mirror URI Templates are shown below.¶

https://mirror.example/mirror{?target}
https://mirror.example/{target}

The Mirror URI Template MUST contain the "target" variable exactly once. The variable MUST be within the path or query components of the URI.¶

In addition, each mirror is configured with a MIN_VALIDITY_WINDOW parameter, which is an integer indicating the minimum time for resources the mirror will cache according to their "max-age" response directive. We refer to the validity window of the mirror response as the period of time determined by the Cache-Control headers as the response.¶

Clients send requests to mirror resources after being configured with their corresponding Mirror URI Template. Clients MUST ignore configurations that do not conform to this template.¶

Upon receipt of a mirror request, mirrors validate the incoming request. If the request is invalid or malformed, e.g., the "target" parameter is not a correctly encoded URL, the mirror aborts and returns a a 4xx (Client Error) to the client. The mirror SHOULD check that the target resource identified by the "target" parameter is allowed by policy, e.g., so that it is not abused to fetch arbitrary resources. One way to implement this check is via an allowlist of target URLs.¶

If the request is valid and allowed, the mirror checks to see if it has a cached version of the resource identified by the target URL. Mirrors can provide a cached response to a client request if the following criteria are met:¶

1. The target URL matches that of a cached response.¶

2. The cached response is fresh according to its Cache-Control header (see Section 4.2 of [CACHING]).¶

If both criteria are met, the mirror encodes the cached response using Binary HTTP [BHTTP] and returns it to the client in a response. The mirror response incldues a Cache-Control header with "max-age" directive set to that of the cached response.¶

Otherwise, mirrors send a GET request to the target resource URL, copying the Accept header from the client request if present. If this request fails, the mirror returns a 4xx error to the client. If this request suceeeds, the mirror checks it for validity. The response is considered valid and stored in the mirror's cache if the following criteria are met:¶

1. The response can be cached according to the rules in Section 3 of [CACHING]. In particular, if the request had a Vary header, this is used in determining whether the mirror's response is valid.¶

2. The Cache-Control header is present, has a "max-age" response directive that is greater than or equal to MIN_VALIDITY_WINDOW, and does not have a "no-store" or "private" directive.¶

Mirrors purge this cache when the response is no longer valid according to the Cache-Control headers.¶

To complete the client request, the mirror then encodes the response using Binary HTTP [BHTTP] and returns it to the client in a response. The mirror response incldues a Cache-Control header with "max-age" directive set to that of the cached response.¶

Clients recover the target's mirrored response by Binary HTTP decoding the mirror response content.¶

:method = GET
:scheme = https
:authority = mirror.example
:path = /mirror?target=https%3A%2F%2Fissuer.example%2F.well-known%2Fprivate-token-issuer-directory
accept = application/private-token-issuer-directory

:method = GET
:scheme = https
:authority = target.example
:path = /.well-known/private-token-issuer-directory
accept = application/private-token-issuer-directory

:status = 200
content-type = application/private-token-issuer-directory
content-length = ...
cache-control: max-age=3600

<Bytes containing a private token issuer directory>

:status = 200
content-length = ...
cache-control: max-age=3600

<Bytes containing the target's BHTTP-encoded response>

:method = GET
:scheme = https
:authority = mirror.example
:path = /mirror?target=https%3A%2F%2Fissuer.example%2F.well-known%2Fprivate-token-issuer-directory

:status = 200
content-length = ...
cache-control: max-age=3600

<Bytes containing the target's BHTTP-encoded response>

5. Using Mirrors for Consistency Checks

Clients can use mirrors to implement consistency checks for a candidate HTTP resource. In particular, in possession of the target URL at which the resource was obtained, as well as an authoritative representation of the resource, clients can check to see if this resource is consistent with that of the mirror's as follows:¶

1. Send a mirror request to the mirror for the target URL. If the request fails, fail this consistency check.¶

2. Otherwise, compute the first valid representation of the resource based on the mirror's response.¶

3. Compare the computed representation to the input resource representation. If they do not match, fail this consistency check. Otherwise, this consistency check succeeds.¶

The benefits of using the mirror protocol to check consistency depend on a multitude of factors, including, but not limited to, the number of clients interacting with a particular mirror, whether or not the mirror is trustworthy, and application requirements for dealing with consistency check failures.¶

{
  "issuer-request-uri": "https://issuer.example.net/request",
  "token-keys": [
    {
      "token-type": 2,
      "token-key": "MI...AB",
      "not-before": 1686913811,
    },
    {
      "token-type": 2,
      "token-key": "MI...AQ",
    }
  ]
}

6. Security Considerations

Consistency checks assume that the client-configured set of mirrors is honest. Under this assumption, the consistency properties of consistency checks based on the mirror protocol are as follows:¶

1. With honest mirrors, clients that successfully check a resource are assured that they share the same copy of the resource with the union of mirror clients for each configured mirror.¶

2. Consistency only holds for the period of time of the minimum mirror validity window.¶

3. With at least one dishonest mirror, the probability of discovering an inconsistency is 1 - (1 / 2^(k-1)), where k is the number of disjoint consistency checks. This is the probability that each individual consistency check succeeds.¶

Unless all clients share the same configured mirrors, consistency checks using the mirror protocol do not achieve global consistency as is defined in [CONSISTENCY].¶

7. IANA Considerations

This document has no IANA actions.¶

Acknowledgments

This document is based on the [DOUBLE-CHECK] protocol from Benjamin Schwartz.¶

Authors' Addresses