Distribution of Oblivious Configurations via Service Binding Records
draft-pauly-ohai-svcb-config-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Tommy Pauly , Tirumaleswar Reddy.K | ||
| Last updated | 2022-03-05 | ||
| Replaced by | draft-ietf-ohai-svcb-config | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-pauly-ohai-svcb-config-00
Oblivious HTTP Application Intermediation T. Pauly
Internet-Draft Apple Inc.
Intended status: Informational T. Reddy
Expires: 6 September 2022 Akamai
5 March 2022
Distribution of Oblivious Configurations via Service Binding Records
draft-pauly-ohai-svcb-config-00
Abstract
This document defines a parameter that can be included in SVCB and
HTTPS DNS resource records to denote that a service is accessible as
an Oblivious HTTP target, along with one or more oblivious key
configurations.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-pauly-ohai-svcb-config/.
Discussion of this document takes place on the Oblivious HTTP
Application Intermediation Working Group mailing list
(mailto:ohai@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/ohai/.
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 6 September 2022.
Pauly & Reddy Expires 6 September 2022 [Page 1]
Internet-Draft Oblivious Configs in SVCB March 2022
Copyright Notice
Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. The ohttp-configs and ohttp-path SvcParamKeys . . . . . . . . 3
3.1. Use in HTTPS service records . . . . . . . . . . . . . . 4
3.2. Use in DNS server SVCB records . . . . . . . . . . . . . 4
3.2.1. Use with DDR . . . . . . . . . . . . . . . . . . . . 4
3.2.2. Use with DNR . . . . . . . . . . . . . . . . . . . . 5
3.2.3. Handling Oblivious DoH Configurations . . . . . . . . 5
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 6
5. Security and Privacy Considerations . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Oblivious HTTP [OHTTP] allows clients to encrypt messages exchanged
with an HTTP server accessed via a proxy, in such a way that the
proxy cannot inspect the contents of the message and the target HTTP
server does not discover the client's identity. In order to use
Oblivious HTTP, clients need to possess a key configuration to use to
encrypt messages to the oblivious target.
Pauly & Reddy Expires 6 September 2022 [Page 2]
Internet-Draft Oblivious Configs in SVCB March 2022
Since Oblivious HTTP deployments will often involve very specific
coordination between clients, proxies, and targets, the key
configuration can often be shared in a bespoke fashion. However,
some deployments involve clients discovering oblivious targets more
dynamically. For example, a network may want to advertise a DNS
resolver that is accessible over Oblivious HTTP and applies local
network resolution policies via mechanisms like Discovery of
Designated Resolvers ([DDR]. Clients can work with trusted proxies
to access these target servers.
This document defines a mechanism to distribute Oblivious HTTP key
configurations in DNS records, as a parameter that can be included in
SVCB and HTTPS DNS resource records [SVCB]. The presence of this
parameter indicates that a service is an oblivious target; see
Section 3 of [OHTTP] for a description of oblivious targets.
This mechanism does not aid in the discovery of proxies to use to
access oblivious targets; the configurations of proxies is out of
scope for this document.
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. The ohttp-configs and ohttp-path SvcParamKeys
The "ohttp-configs" SvcParamKey Section 6 is used to convey one or
more key configurations that can be used by clients to issue
oblivious requests to a target server described by the SVCB record.
In wire format, the value of the parameter is one or more KeyConfig
structures [OHTTP] concatenated together. In presentation format,
the value is the same concatenated KeyConfig structures encoded in
Base64 [BASE64].
The meaning of the "ohttp-configs" parameter depends on the scheme of
the SVCB record. This document defines the interpretation for the
"https" [SVCB] and "dns" [DNS-SVCB] schemes. Other schemes that want
to use this parameter MUST define the interpretation and meaning of
the configuration.
The "ohttp-path" SvcParamKey Section 6 is used to convey the URI path
of the oblivious target to which oblivious HTTP requests can sent.
In both wire format and presentation format, this is a UTF-8 encoded
Pauly & Reddy Expires 6 September 2022 [Page 3]
Internet-Draft Oblivious Configs in SVCB March 2022
string that contains the path segment of a URI. If this path
parameter is not present, oblivious requests can be made to the root
"/" path.
3.1. Use in HTTPS service records
For the "https" scheme, which uses the HTTPS RR type instead of SVCB,
the presence of the "ohttp-configs" parameter means that the service
being described is an Oblivious HTTP service that uses the default
"message/bhttp" media type [OHTTP] [BINARY-HTTP].
When present in an HTTPS record, the "ohttp-configs" MUST be included
in the mandatory parameter list, to ensure that implementations that
do not understand the key do not interpret this service as a generic
HTTP service.
Clients MUST validate that they can parse the value of "ohttp-
configs" as a valid key configuration before attempting to use the
service.
3.2. Use in DNS server SVCB records
For the "dns" scheme, as defined in [DNS-SVCB], the presence of the
"ohttp-configs" parameter means that the DNS server being described
is an Oblivious DNS over HTTP (DoH) service. The default media type
expected for use in Oblivious HTTP to DNS resolvers is "application/
dns-message" [DOH].
The "ohttp-configs" parameter is only defined for use with DoH, so
the "alpn" SvcParamKey MUST indicate support for a version of HTTP
and the "dohpath" SvcParamKey MUST be present. The "ohttp-configs"
MUST also be included in the mandatory parameter list, to ensure that
implementations that do not understand the key do not interpret this
service as a generic DoH service.
Clients MUST validate that they can parse the value of "ohttp-
configs" as a valid key configuration before attempting to use the
service.
3.2.1. Use with DDR
Clients can discover an oblivious DNS server configuration using DDR,
by either querying _dns.resolver.arpa to a locally configured
resolver or querying using the name of a resolver [DDR].
In the case of oblivious DNS servers, the client might not be able to
directly use the verification mechanisms described in [DDR], which
rely on checking for known resolver IP addresses or hostnames in TLS
Pauly & Reddy Expires 6 September 2022 [Page 4]
Internet-Draft Oblivious Configs in SVCB March 2022
certificates, since clients do not generally perform TLS with
oblivious targets. A client MAY perform a direct connection to the
oblivious target server to do this TLS check, however this may be
impossible or undesirable if the client does not want to ever expose
its IP address to the oblivious target. If the client does not use
the standard DDR verification check, it MUST use some alternate
mechanism to verify that it should use an oblivious target. For
example, the client could have a local policy of known oblivious
target names that it is allowed to use, or the client could
coordinate with the oblivious proxy to either have the oblivious
proxy check the properties of the target's TLS certificate or filter
to only allow targets known and trusted by the proxy.
Clients also need to ensure that they are not being targeted with
unique key configurations that would reveal their identity. See
Section 5 for more discussion.
3.2.2. Use with DNR
The SvcParamKeys defined in this document also can be used with
Discovery of Network-designated Resolvers (DNR) [DNR]. In this case,
the oblivious configuration and path parameters can be included in
DHCP and Router Advertisement messages.
While DNR does not require the same kind of verification as DDR,
clients still need to ensure that they are not being targeted with
unique key configurations that would reveal their identity. See
Section 5 for more discussion.
3.2.3. Handling Oblivious DoH Configurations
Oblivious DoH was originally defined in [ODOH]. This version of
Oblivious DoH uses a different key configuration format than generic
Oblivious HTTP. SVCB records using the "dns" scheme can include one
or more ObliviousDoHConfig structures using the "odoh-configs"
parameter.
In wire format, the value of the "odoh-configs" parameter is one or
more ObliviousDoHConfigs structures [ODOH] concatenated together. In
presentation format, the value is the same structures encoded in
Base64 [BASE64].
All other requirements for "ohttp-configs" in this document apply to
"odoh-configs".
Pauly & Reddy Expires 6 September 2022 [Page 5]
Internet-Draft Oblivious Configs in SVCB March 2022
4. Deployment Considerations
Deployments that add the "ohttp-configs" SvcParamKey need to be
careful to add this only to services meant to be accessed using
Oblivious HTTP. Information in a single SVCB record that contains
"ohttp-configs" only applies to the oblivious service, not other HTTP
services.
If a service offers both traditional HTTP and oblivious HTTP, these
can be represented by separate SVCB or HTTPS records, both with and
without the "ohttp-configs" SvcParamKey.
5. Security and Privacy Considerations
When discovering designated oblivious DNS servers using this
mechanism, clients need to ensure that the designation is trusted in
lieu of being able to directly check the contents of the target
server's TLS certificate. See Section 3.2.1 for more discussion.
As discussed in [OHTTP], client requests using Oblivious HTTP can
only be linked by recognizing the key configuration. In order to
prevent unwanted linkability and tracking, clients using any key
configuration discovery mechanism need to be concerned with attacks
that target a specific user or population with a unique key
configuration.
There are several approaches clients can use to mitigate key
targetting attacks. [CONSISTENCY] provides an analysis of the
options for ensuring the key configurations are consistent between
different clients. Clients SHOULD employ some technique to mitigate
key targetting attack. One mitigation specific to this mechanism is
validating that SVCB or HTTPS records including the "oblivious-
configs" are protected by DNSSEC [DNSSEC]. This prevents attacks
where a unique response is generated for each client of a resolver.
6. IANA Considerations
IANA is requested to add the following entry to the SVCB Service
Parameters registry ([SVCB]).
Pauly & Reddy Expires 6 September 2022 [Page 6]
Internet-Draft Oblivious Configs in SVCB March 2022
+========+===============+====================+===========+
| Number | Name | Meaning | Reference |
+========+===============+====================+===========+
| TBD | ohttp-configs | Oblivious HTTP key | (This |
| | | configurations | document) |
+--------+---------------+--------------------+-----------+
| TBD | ohttp-path | Oblivious HTTP | (This |
| | | request path | document) |
+--------+---------------+--------------------+-----------+
| TBD | odoh-configs | Oblivious DoH key | (This |
| | | configurations | document) |
+--------+---------------+--------------------+-----------+
Table 1
7. References
7.1. Normative References
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[BINARY-HTTP]
Thomson, M. and C. A. Wood, "Binary Representation of HTTP
Messages", Work in Progress, Internet-Draft, draft-ietf-
httpbis-binary-message-01, 3 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
binary-message-01>.
[DDR] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
Jensen, "Discovery of Designated Resolvers", Work in
Progress, Internet-Draft, draft-ietf-add-ddr-05, 31
January 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-add-ddr-05>.
[DNR] Boucadair, M., Reddy, T., Wing, D., Cook, N., and T.
Jensen, "DHCP and Router Advertisement Options for the
Discovery of Network-designated Resolvers (DNR)", Work in
Progress, Internet-Draft, draft-ietf-add-dnr-05, 13
December 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-add-dnr-05>.
[DNS-SVCB] Schwartz, B., "Service Binding Mapping for DNS Servers",
Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns-
02, 1 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-add-
svcb-dns-02>.
Pauly & Reddy Expires 6 September 2022 [Page 7]
Internet-Draft Oblivious Configs in SVCB March 2022
[DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>.
[OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
Progress, Internet-Draft, draft-ietf-ohai-ohttp-01, 15
February 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-ohai-ohttp-01>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service binding
and parameter specification via the DNS (DNS SVCB and
HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-
dnsop-svcb-https-08, 12 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
svcb-https-08>.
7.2. Informative References
[CONSISTENCY]
Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
"Key Consistency and Discovery", Work in Progress,
Internet-Draft, draft-wood-key-consistency-02, 4 March
2022, <https://datatracker.ietf.org/doc/html/draft-wood-
key-consistency-02>.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/rfc/rfc4033>.
[ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A.
Wood, "Oblivious DNS Over HTTPS", Work in Progress,
Internet-Draft, draft-pauly-dprive-oblivious-doh-11, 17
February 2022, <https://datatracker.ietf.org/doc/html/
draft-pauly-dprive-oblivious-doh-11>.
Authors' Addresses
Pauly & Reddy Expires 6 September 2022 [Page 8]
Internet-Draft Oblivious Configs in SVCB March 2022
Tommy Pauly
Apple Inc.
Email: tpauly@apple.com
Tirumaleswar Reddy
Akamai
Email: kondtir@gmail.com
Pauly & Reddy Expires 6 September 2022 [Page 9]