idnits 2.17.1 draft-schwartz-ohai-consistency-doublecheck-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 April 2022) is 750 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-cache' -- Duplicate reference: draft-ietf-httpbis-cache, mentioned in 'I-D.ietf-httpbis-cache-19', was also mentioned in 'I-D.ietf-httpbis-cache'. -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-cache-19' == Outdated reference: A later version (-15) exists of draft-ietf-masque-connect-udp-08 == Outdated reference: A later version (-10) exists of draft-ietf-ohai-ohttp-01 == Outdated reference: A later version (-03) exists of draft-schwartz-masque-access-descriptions-00 ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) == Outdated reference: A later version (-03) exists of draft-wood-key-consistency-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ohai B. M. Schwartz 3 Internet-Draft Google LLC 4 Intended status: Standards Track 7 April 2022 5 Expires: 9 October 2022 7 Key Consistency for Oblivious HTTP by Double-Checking 8 draft-schwartz-ohai-consistency-doublecheck-00 10 Abstract 12 The assurances provided by Oblivious HTTP depend on the client's 13 ability to verify that it is using the same Request Resource and 14 KeyConfig as many other users. This specification defines a protocol 15 to enable this verification. 17 About This Document 19 This note is to be removed before publishing as an RFC. 21 Status information for this document may be found at 22 https://datatracker.ietf.org/doc/draft-schwartz-ohai-consistency- 23 doublecheck/. 25 Source for this draft and an issue tracker can be found at 26 https://github.com/bemasc/access-services. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 9 October 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. Oblivious Request Resource . . . . . . . . . . . . . . . 4 66 4.2. Oblivious Proxy . . . . . . . . . . . . . . . . . . . . . 4 67 4.3. Client . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Example: Oblivious DoH . . . . . . . . . . . . . . . . . . . 6 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 6.1. In scope . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6.2. Out of scope . . . . . . . . . . . . . . . . . . . . . . 9 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 8.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 Oblivious HTTP [I-D.ietf-ohai-ohttp] presumes at least three parties 82 to each exchange: the client, the proxy, and the target (formally, 83 the Oblivious Request Resource). When used properly, Oblivious HTTP 84 enables the client to send requests to the target in such a way that 85 the target cannot tell whether two requests came from the same client 86 and the proxy cannot see the contents of the requests. 88 Oblivious HTTP's threat model assumes that at least one of the proxy 89 and the target is acting properly, i.e. complying with the protocol 90 and keeping certain information confidential. If either proxy or 91 target misbehaves, the only effect must be a denial of service. 93 In order for these security guarantees to hold, several preconditions 94 must be met: 96 1. The client must be one of many users who might be using the 97 proxy. Otherwise, use of the proxy reveals the user's identity 98 to the target. 100 2. The client must hold an authentic KeyConfig for the target. 101 Otherwise, they could be speaking to the proxy, impersonating the 102 target. 104 3. All users of this proxy must be equally likely to use this URI 105 and KeyConfig for this target, regardless of their prior 106 activity. Otherwise, the encrypted request identifies the user 107 to the target. 109 4. (optional) The target must not learn the IP addresses of the 110 clients, collectively. Otherwise, the target might be able to 111 deanonymize requests by correlating them with external 112 information about the clients. 114 This specification defines behaviors for the client, proxy, and 115 target that achieve preconditions 2-4. (This specification does not 116 address precondition 1.) 118 This draft is an instantiation of the "Single Proxy Discovery" 119 architecture for key consistency, defined in Section 4.2 of 120 [I-D.wood-key-consistency]. 122 2. Conventions and Definitions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 3. Overview 132 In the Key Consistency Double-Check procedure, the Client emits two 133 requests: one to the Proxy, and one through the Proxy to the Target. 134 The Proxy will forward the first request to the Target if the 135 response is not in cache. 137 +--------+ +-------+ +--------+ 138 | |<=====>| |<---->| | 139 | Client | | Proxy | | Target | 140 | |<====================>| | 141 +--------+ +-------+ +--------+ 143 Figure 1: Overview of Key-Consistency Double-Check 145 The proxy caches the response, ensuring that all clients share it 146 during its freshness lifetime. The client checks this against the 147 authenticated response from the Target, preventing forgeries. 149 4. Requirements 151 4.1. Oblivious Request Resource 153 The Oblivious Request Resource MUST publish an Access Description 154 [I-D.schwartz-masque-access-descriptions] over HTTP/3 containing the 155 ohttp.request key, e.g.: 157 { 158 "ohttp": { 159 "request": { 160 "uri": "https://example.com/ohttp/", 161 "key": "(KeyConfig in Base64)" 162 } 163 } 164 } 166 The Oblivious Request Resource MUST include a "strong validator" ETag 167 (Section 2 of [RFC7232]) in any response to a GET request for this 168 access description, and MUST support the "If-Match" HTTP request 169 header (Section 3 of [RFC7232]). The response MUST indicate "Cache- 170 Control: public, no-transform, s-maxage=(...), immutable" 171 [I-D.ietf-httpbis-cache][RFC8246]. For efficiency reasons, the max 172 age SHOULD be at least 60 seconds, and preferably much longer. 174 If this Access Description changes, and the resource receives a 175 request whose "If-Match" header identifies a previously served 176 version that has not yet expired, it MUST return a success response 177 containing the previous version. This response MAY indicate "Cache- 178 Control: private". 180 4.2. Oblivious Proxy 182 The Oblivious Proxy MUST publish an Access Description that includes 183 the ohttp.proxy and udp keys, indicating support for CONNECT-UDP 184 [I-D.ietf-masque-connect-udp]. It SHOULD also contain the dns key, 185 indicating support for DNS over HTTPS [RFC8484], to enable the use of 186 HTTPS records with CONNECT-UDP. 188 { 189 "dns": { 190 "template": "https://doh.example.com/dns-query{?dns}", 191 }, 192 "udp": { 193 "template": 194 "https://proxy.example.org/masque{?target_host,target_port}" 195 }, 196 "ohttp": { 197 "proxy": { 198 "template": "https://proxy.example.org/ohttp{?request_uri}" 199 } 200 } 201 } 203 Figure 2: Example Proxy Access Description 205 The Oblivious Proxy Resources MUST allow use of the GET method to 206 retrieve small JSON responses, and SHOULD make ample cache space 207 available in order to cache Access Descriptions. Each proxy instance 208 (as defined by its external-facing network interface) MUST share 209 cache state among all clients to ensure that they use the same Access 210 Descriptions for each Oblivious Request Resource. 212 Oblivious Proxies MUST preserve the ETag response header on cached 213 responses, and MUST add an Age header ([I-D.ietf-httpbis-cache-19], 214 Section 5.1) to all proxied responses. Oblivious Proxies MUST 215 respect the "Cache-Control: immutable" directive, never revalidating 216 these cached entries, and MUST NOT accept PUSH_PROMISE frames from 217 the target. 219 Proxies SHOULD employ defenses against malicious attempts to fill the 220 cache. Some possible defenses include: 222 * Rate-limiting each client's use of GET requests. 224 * Prioritizing preservation of cache entries that have been served 225 to many clients, if eviction is required. 227 Oblivious Proxies that are not intended for general-purpose proxy 228 usage MAY impose strict transfer limits or rate limits on HTTP 229 CONNECT and CONNECT-UDP usage. 231 4.3. Client 233 The Client is assumed to know an "https" URI of an Oblivious Request 234 Resource's Access Description. To use that Request Resource, it MUST 235 perform the following "double-check" procedure: 237 1. Send a GET request to the Oblivious Proxy's template with 238 request_uri set to the Access Description URI. 240 2. Record the response (A). 242 3. Check that response A's "Cache-Control" values indicates "public" 243 and "immutable". 245 4. Fetch the Access Description URI from its origin via CONNECT-UDP, 246 with "If-Match" set to response A's ETag. 248 5. Record the response (B). 250 6. Check that responses A and B were successful and the contents are 251 identical, otherwise fail. 253 This procedure ensures that the Access Description is authentic and 254 will be shared by all users of this proxy. Once response A or B 255 expires, the client MUST refresh it before continuing to use this 256 Access Description, and MUST repeat the "double-check" process if 257 either response changes. 259 5. Example: Oblivious DoH 261 In this example, the client has been configured with an Oblivious DoH 262 server and an Oblivious Proxy. The Oblivious DoH server is 263 identified by an Access Description at "https://doh.example.com/ 264 config.json" with the following contents: 266 { 267 "dns": { 268 "template": "https://doh.example.com/dns-query{?dns}", 269 }, 270 "ohttp": { 271 "request": { 272 "uri": "https://example.com/ohttp/", 273 "key": "(KeyConfig in Base64)" 274 } 275 } 276 } 278 The Oblivious Proxy is identified as "proxy.example.org", which 279 implies an Access Description at "https://proxy.example.org/.well- 280 known/access-services". This resource's contents are: 282 { 283 "dns": { 284 "template": "https://proxy.example.org/dns-query{?dns}", 285 }, 286 "udp": { 287 "template": 288 "https://proxy.example.org/masque{?target_host,target_port}" 289 }, 290 "ohttp": { 291 "proxy": { 292 "template": "https://proxy.example.org/ohttp{?request_uri}" 293 } 294 } 295 } 297 The following exchanges then occur between the client and the proxy: 299 HEADERS 300 :method = GET 301 :scheme = https 302 :authority = proxy.example.org 303 :path = /ohttp?request_uri=https%3A%2F%2Fdoh.example.com%2Fconfig.json 304 accept: application/json 306 HEADERS 307 :status = 200 308 cache-control: public, immutable, \ 309 no-transform, s-maxage=86400 310 age: 80000 311 etag: ABCD1234 312 content-type: application/json 313 [Access Description contents here] 315 HEADERS 316 :method = CONNECT 317 :protocol = connect-udp 318 :scheme = https 319 :authority = proxy.example.org 320 :path = /masque?target_host=doh.example.com,target_port=443 321 capsule-protocol = ?1 323 HEADERS 324 :status = 200 325 capsule-protocol = ?1 327 The client now has a CONNECT-UDP tunnel to doh.example.com, over 328 which it performs the following request using HTTP/3: 330 HEADERS 331 :method = GET 332 :scheme = https 333 :authority = doh.example.com 334 :path = /config.json 335 if-match = ABCD1234 337 HEADERS 338 :status = 200 339 cache-control: public, immutable, \ 340 no-transform, s-maxage=86400 341 etag: ABCD1234 342 content-type: application/json 343 [Access Description contents here] 345 Having successfully fetched the Access Description from both 346 locations, the client confirms that: 348 * The responses are identical. 350 * The cache-control response from the proxy contained the "public" 351 and "immutable" directives. 353 The client can now use the KeyConfig in this Access Description to 354 reach the Oblivious DoH server, by forming Binary HTTP requests for 355 "https://doh.example.com/dns-query" and delivering the encapsulated 356 requests to "https://example.com/ohttp/" via the proxy. 358 6. Security Considerations 360 6.1. In scope 362 A malicious proxy could attempt to learn the contents of the 363 oblivious request by forging an Access Description containing its own 364 KeyConfig. This is prevented by the client's requirement that the 365 KeyConfig be served to it by the configured origin over HTTPS 366 (Section 4.3). 368 A malicious target could attempt to link multiple requests together 369 by issuing each user a unique, persistent KeyConfig. This attack is 370 prevented by the client's requirement that the KeyConfig be fresh 371 according to the proxy's cache (Section 4.3). 373 A malicious target could attempt to rotate its entry in the proxy's 374 cache in several ways: 376 * Using HTTP PUSH_PROMISE frames. This attack is prevented by 377 disabling PUSH_PROMISE at the proxy (Section 4.2). 379 * By also acting as a client and sending requests designed to 380 replace the Access Description in the cache before it expires: 382 - By sending requests with a "Cache-Control: no-cache" or similar 383 directive. This is prevented by the response's "Cache-Control: 384 public, immutable" directives, which are verified by the client 385 (Section 4.3). 387 - By filling the cache with new entries, causing its previous 388 Access Description to be evicted. Section 4.2 describes some 389 possible mitigations. 391 A malicious client could use the proxy to send abusive traffic to any 392 destination on the internet. Abuse concerns can be mitigated by 393 imposing a rate limit at the proxy (Section 4.2). 395 6.2. Out of scope 397 This specification assumes that the client starts with identities of 398 the proxy and target that are authentic and widely shared. If these 399 identities are inauthentic, or are unique to the user, then the 400 security goals of this specification are not achieved. 402 This specification assumes that at most a small fraction of clients 403 are acting on behalf of a malicious target. If a large fraction of 404 the clients are malicious, they could conspire to flood the proxy 405 cache with entries that seem popular, leading to rapid eviction of 406 the malicious target's Access Descriptions. Similar concerns apply 407 if a malicious target can compel naive clients to fetch a very large 408 number of Access Descriptions. 410 7. IANA Considerations 412 IANA is requested to open a Specification Required registry entitled 413 "HTTP Access Service Descriptors", with the following initial 414 contents: 416 +=======+=================+ 417 | Key | Specification | 418 +=======+=================+ 419 | dns | (This document) | 420 +-------+-----------------+ 421 | udp | (This document) | 422 +-------+-----------------+ 423 | ip | (This document) | 424 +-------+-----------------+ 425 | ohttp | (This document) | 426 +-------+-----------------+ 428 Table 1 430 IANA is requested to add the following entry to the "Well-Known URIs" 431 registry 433 +=================+============+=========+===========+==============+ 434 | URI Suffix | Change |Reference| Status | Related | 435 | | Controller | | | Information | 436 +=================+============+=========+===========+==============+ 437 | access-services | IETF |(This | permanent | Sub-registry | 438 | | |document)| | at (link) | 439 +-----------------+------------+---------+-----------+--------------+ 441 Table 2 443 8. References 445 8.1. Normative References 447 [I-D.ietf-httpbis-cache] 448 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 449 Caching", Work in Progress, Internet-Draft, draft-ietf- 450 httpbis-cache-19, 12 September 2021, 451 . 454 [I-D.ietf-httpbis-cache-19] 455 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 456 Caching", Work in Progress, Internet-Draft, draft-ietf- 457 httpbis-cache-19, 12 September 2021, 458 . 461 [I-D.ietf-masque-connect-udp] 462 Schinazi, D., "UDP Proxying Support for HTTP", Work in 463 Progress, Internet-Draft, draft-ietf-masque-connect-udp- 464 08, 21 March 2022, . 467 [I-D.ietf-ohai-ohttp] 468 Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in 469 Progress, Internet-Draft, draft-ietf-ohai-ohttp-01, 15 470 February 2022, . 473 [I-D.schwartz-masque-access-descriptions] 474 Schwartz, B. M., "HTTP Access Service Description 475 Objects", Work in Progress, Internet-Draft, draft- 476 schwartz-masque-access-descriptions-00, 7 April 2022, 477 . 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, 482 DOI 10.17487/RFC2119, March 1997, 483 . 485 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 486 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 487 DOI 10.17487/RFC7232, June 2014, 488 . 490 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 491 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 492 May 2017, . 494 [RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246, 495 DOI 10.17487/RFC8246, September 2017, 496 . 498 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 499 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 500 . 502 8.2. Informative References 504 [I-D.wood-key-consistency] 505 Davidson, A., Finkel, M., Thomson, M., and C. A. Wood, 506 "Key Consistency and Discovery", Work in Progress, 507 Internet-Draft, draft-wood-key-consistency-02, 4 March 508 2022, . 511 Acknowledgments 513 TODO acknowledge. 515 Author's Address 517 Benjamin M. Schwartz 518 Google LLC 519 Email: bemasc@google.com