idnits 2.17.1 draft-pauly-ohai-svcb-config-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (5 March 2022) is 783 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-binary-message-01 == Outdated reference: A later version (-10) exists of draft-ietf-add-ddr-05 == Outdated reference: A later version (-16) exists of draft-ietf-add-dnr-05 == Outdated reference: A later version (-09) exists of draft-ietf-add-svcb-dns-02 == Outdated reference: A later version (-10) exists of draft-ietf-ohai-ohttp-01 == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-08 == Outdated reference: A later version (-03) exists of draft-wood-key-consistency-02 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Oblivious HTTP Application Intermediation T. Pauly 3 Internet-Draft Apple Inc. 4 Intended status: Informational T. Reddy 5 Expires: 6 September 2022 Akamai 6 5 March 2022 8 Distribution of Oblivious Configurations via Service Binding Records 9 draft-pauly-ohai-svcb-config-00 11 Abstract 13 This document defines a parameter that can be included in SVCB and 14 HTTPS DNS resource records to denote that a service is accessible as 15 an Oblivious HTTP target, along with one or more oblivious key 16 configurations. 18 About This Document 20 This note is to be removed before publishing as an RFC. 22 Status information for this document may be found at 23 https://datatracker.ietf.org/doc/draft-pauly-ohai-svcb-config/. 25 Discussion of this document takes place on the Oblivious HTTP 26 Application Intermediation Working Group mailing list 27 (mailto:ohai@ietf.org), which is archived at 28 https://mailarchive.ietf.org/arch/browse/ohai/. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 6 September 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 65 3. The ohttp-configs and ohttp-path SvcParamKeys . . . . . . . . 3 66 3.1. Use in HTTPS service records . . . . . . . . . . . . . . 4 67 3.2. Use in DNS server SVCB records . . . . . . . . . . . . . 4 68 3.2.1. Use with DDR . . . . . . . . . . . . . . . . . . . . 4 69 3.2.2. Use with DNR . . . . . . . . . . . . . . . . . . . . 5 70 3.2.3. Handling Oblivious DoH Configurations . . . . . . . . 5 71 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 72 5. Security and Privacy Considerations . . . . . . . . . . . . . 6 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 7.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 Oblivious HTTP [OHTTP] allows clients to encrypt messages exchanged 82 with an HTTP server accessed via a proxy, in such a way that the 83 proxy cannot inspect the contents of the message and the target HTTP 84 server does not discover the client's identity. In order to use 85 Oblivious HTTP, clients need to possess a key configuration to use to 86 encrypt messages to the oblivious target. 88 Since Oblivious HTTP deployments will often involve very specific 89 coordination between clients, proxies, and targets, the key 90 configuration can often be shared in a bespoke fashion. However, 91 some deployments involve clients discovering oblivious targets more 92 dynamically. For example, a network may want to advertise a DNS 93 resolver that is accessible over Oblivious HTTP and applies local 94 network resolution policies via mechanisms like Discovery of 95 Designated Resolvers ([DDR]. Clients can work with trusted proxies 96 to access these target servers. 98 This document defines a mechanism to distribute Oblivious HTTP key 99 configurations in DNS records, as a parameter that can be included in 100 SVCB and HTTPS DNS resource records [SVCB]. The presence of this 101 parameter indicates that a service is an oblivious target; see 102 Section 3 of [OHTTP] for a description of oblivious targets. 104 This mechanism does not aid in the discovery of proxies to use to 105 access oblivious targets; the configurations of proxies is out of 106 scope for this document. 108 2. Conventions and Definitions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in 113 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 3. The ohttp-configs and ohttp-path SvcParamKeys 118 The "ohttp-configs" SvcParamKey Section 6 is used to convey one or 119 more key configurations that can be used by clients to issue 120 oblivious requests to a target server described by the SVCB record. 122 In wire format, the value of the parameter is one or more KeyConfig 123 structures [OHTTP] concatenated together. In presentation format, 124 the value is the same concatenated KeyConfig structures encoded in 125 Base64 [BASE64]. 127 The meaning of the "ohttp-configs" parameter depends on the scheme of 128 the SVCB record. This document defines the interpretation for the 129 "https" [SVCB] and "dns" [DNS-SVCB] schemes. Other schemes that want 130 to use this parameter MUST define the interpretation and meaning of 131 the configuration. 133 The "ohttp-path" SvcParamKey Section 6 is used to convey the URI path 134 of the oblivious target to which oblivious HTTP requests can sent. 135 In both wire format and presentation format, this is a UTF-8 encoded 136 string that contains the path segment of a URI. If this path 137 parameter is not present, oblivious requests can be made to the root 138 "/" path. 140 3.1. Use in HTTPS service records 142 For the "https" scheme, which uses the HTTPS RR type instead of SVCB, 143 the presence of the "ohttp-configs" parameter means that the service 144 being described is an Oblivious HTTP service that uses the default 145 "message/bhttp" media type [OHTTP] [BINARY-HTTP]. 147 When present in an HTTPS record, the "ohttp-configs" MUST be included 148 in the mandatory parameter list, to ensure that implementations that 149 do not understand the key do not interpret this service as a generic 150 HTTP service. 152 Clients MUST validate that they can parse the value of "ohttp- 153 configs" as a valid key configuration before attempting to use the 154 service. 156 3.2. Use in DNS server SVCB records 158 For the "dns" scheme, as defined in [DNS-SVCB], the presence of the 159 "ohttp-configs" parameter means that the DNS server being described 160 is an Oblivious DNS over HTTP (DoH) service. The default media type 161 expected for use in Oblivious HTTP to DNS resolvers is "application/ 162 dns-message" [DOH]. 164 The "ohttp-configs" parameter is only defined for use with DoH, so 165 the "alpn" SvcParamKey MUST indicate support for a version of HTTP 166 and the "dohpath" SvcParamKey MUST be present. The "ohttp-configs" 167 MUST also be included in the mandatory parameter list, to ensure that 168 implementations that do not understand the key do not interpret this 169 service as a generic DoH service. 171 Clients MUST validate that they can parse the value of "ohttp- 172 configs" as a valid key configuration before attempting to use the 173 service. 175 3.2.1. Use with DDR 177 Clients can discover an oblivious DNS server configuration using DDR, 178 by either querying _dns.resolver.arpa to a locally configured 179 resolver or querying using the name of a resolver [DDR]. 181 In the case of oblivious DNS servers, the client might not be able to 182 directly use the verification mechanisms described in [DDR], which 183 rely on checking for known resolver IP addresses or hostnames in TLS 184 certificates, since clients do not generally perform TLS with 185 oblivious targets. A client MAY perform a direct connection to the 186 oblivious target server to do this TLS check, however this may be 187 impossible or undesirable if the client does not want to ever expose 188 its IP address to the oblivious target. If the client does not use 189 the standard DDR verification check, it MUST use some alternate 190 mechanism to verify that it should use an oblivious target. For 191 example, the client could have a local policy of known oblivious 192 target names that it is allowed to use, or the client could 193 coordinate with the oblivious proxy to either have the oblivious 194 proxy check the properties of the target's TLS certificate or filter 195 to only allow targets known and trusted by the proxy. 197 Clients also need to ensure that they are not being targeted with 198 unique key configurations that would reveal their identity. See 199 Section 5 for more discussion. 201 3.2.2. Use with DNR 203 The SvcParamKeys defined in this document also can be used with 204 Discovery of Network-designated Resolvers (DNR) [DNR]. In this case, 205 the oblivious configuration and path parameters can be included in 206 DHCP and Router Advertisement messages. 208 While DNR does not require the same kind of verification as DDR, 209 clients still need to ensure that they are not being targeted with 210 unique key configurations that would reveal their identity. See 211 Section 5 for more discussion. 213 3.2.3. Handling Oblivious DoH Configurations 215 Oblivious DoH was originally defined in [ODOH]. This version of 216 Oblivious DoH uses a different key configuration format than generic 217 Oblivious HTTP. SVCB records using the "dns" scheme can include one 218 or more ObliviousDoHConfig structures using the "odoh-configs" 219 parameter. 221 In wire format, the value of the "odoh-configs" parameter is one or 222 more ObliviousDoHConfigs structures [ODOH] concatenated together. In 223 presentation format, the value is the same structures encoded in 224 Base64 [BASE64]. 226 All other requirements for "ohttp-configs" in this document apply to 227 "odoh-configs". 229 4. Deployment Considerations 231 Deployments that add the "ohttp-configs" SvcParamKey need to be 232 careful to add this only to services meant to be accessed using 233 Oblivious HTTP. Information in a single SVCB record that contains 234 "ohttp-configs" only applies to the oblivious service, not other HTTP 235 services. 237 If a service offers both traditional HTTP and oblivious HTTP, these 238 can be represented by separate SVCB or HTTPS records, both with and 239 without the "ohttp-configs" SvcParamKey. 241 5. Security and Privacy Considerations 243 When discovering designated oblivious DNS servers using this 244 mechanism, clients need to ensure that the designation is trusted in 245 lieu of being able to directly check the contents of the target 246 server's TLS certificate. See Section 3.2.1 for more discussion. 248 As discussed in [OHTTP], client requests using Oblivious HTTP can 249 only be linked by recognizing the key configuration. In order to 250 prevent unwanted linkability and tracking, clients using any key 251 configuration discovery mechanism need to be concerned with attacks 252 that target a specific user or population with a unique key 253 configuration. 255 There are several approaches clients can use to mitigate key 256 targetting attacks. [CONSISTENCY] provides an analysis of the 257 options for ensuring the key configurations are consistent between 258 different clients. Clients SHOULD employ some technique to mitigate 259 key targetting attack. One mitigation specific to this mechanism is 260 validating that SVCB or HTTPS records including the "oblivious- 261 configs" are protected by DNSSEC [DNSSEC]. This prevents attacks 262 where a unique response is generated for each client of a resolver. 264 6. IANA Considerations 266 IANA is requested to add the following entry to the SVCB Service 267 Parameters registry ([SVCB]). 269 +========+===============+====================+===========+ 270 | Number | Name | Meaning | Reference | 271 +========+===============+====================+===========+ 272 | TBD | ohttp-configs | Oblivious HTTP key | (This | 273 | | | configurations | document) | 274 +--------+---------------+--------------------+-----------+ 275 | TBD | ohttp-path | Oblivious HTTP | (This | 276 | | | request path | document) | 277 +--------+---------------+--------------------+-----------+ 278 | TBD | odoh-configs | Oblivious DoH key | (This | 279 | | | configurations | document) | 280 +--------+---------------+--------------------+-----------+ 282 Table 1 284 7. References 286 7.1. Normative References 288 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 289 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 290 . 292 [BINARY-HTTP] 293 Thomson, M. and C. A. Wood, "Binary Representation of HTTP 294 Messages", Work in Progress, Internet-Draft, draft-ietf- 295 httpbis-binary-message-01, 3 February 2022, 296 . 299 [DDR] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. 300 Jensen, "Discovery of Designated Resolvers", Work in 301 Progress, Internet-Draft, draft-ietf-add-ddr-05, 31 302 January 2022, . 305 [DNR] Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. 306 Jensen, "DHCP and Router Advertisement Options for the 307 Discovery of Network-designated Resolvers (DNR)", Work in 308 Progress, Internet-Draft, draft-ietf-add-dnr-05, 13 309 December 2021, . 312 [DNS-SVCB] Schwartz, B., "Service Binding Mapping for DNS Servers", 313 Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns- 314 02, 1 February 2022, 315 . 318 [DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 319 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 320 . 322 [OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in 323 Progress, Internet-Draft, draft-ietf-ohai-ohttp-01, 15 324 February 2022, . 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, 329 DOI 10.17487/RFC2119, March 1997, 330 . 332 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 333 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 334 May 2017, . 336 [SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service binding 337 and parameter specification via the DNS (DNS SVCB and 338 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 339 dnsop-svcb-https-08, 12 October 2021, 340 . 343 7.2. Informative References 345 [CONSISTENCY] 346 Davidson, A., Finkel, M., Thomson, M., and C. A. Wood, 347 "Key Consistency and Discovery", Work in Progress, 348 Internet-Draft, draft-wood-key-consistency-02, 4 March 349 2022, . 352 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 353 Rose, "DNS Security Introduction and Requirements", 354 RFC 4033, DOI 10.17487/RFC4033, March 2005, 355 . 357 [ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. 358 Wood, "Oblivious DNS Over HTTPS", Work in Progress, 359 Internet-Draft, draft-pauly-dprive-oblivious-doh-11, 17 360 February 2022, . 363 Authors' Addresses 364 Tommy Pauly 365 Apple Inc. 366 Email: tpauly@apple.com 368 Tirumaleswar Reddy 369 Akamai 370 Email: kondtir@gmail.com