Discovery of Oblivious Services via Service Binding Records

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 26 November 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

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.¶

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 advertise that an HTTP service supports Oblivious HTTP using 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 has an oblivious target; see Section 3 of [OHTTP] for a description of oblivious targets.¶

This document also defines a well-known URI [RFC8615], "oblivious-configs", that can be used to look up key configurations on a service that is known to have an oblivious target.¶

This mechanism does not aid in the discovery of proxies to use to access oblivious targets; the configuration 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 oblivious SvcParamKey

The "oblivious" SvcParamKey Section 6 is used to indicate that a service described in an SVCB record can act as an oblivious target. Clients can issue requests to this service through an oblivious proxy once they learn the key configuration to use to encrypt messages to the oblivious target.¶

Both the presentation and wire format values for the "oblivious" parameter MUST be empty.¶

The "oblivious" parameter can be included in the mandatory parameter list to ensure that clients that do not support oblivious access do not try to use the service. Services that include mark oblivious support as mandatory can, therefore, indicate that the service might not be accessible in a non-oblivious fashion. Services that are intended to be accessed either as an oblivious target or directly SHOULD NOT mark the "oblivious" parameter as mandatory. Note that since multiple SVCB responses can be provided for a single query, the oblivious and non-oblivious versions of a single service can have different SVCB records to support different names or properties.¶

The scheme to use for oblivious requests made to a service 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.¶

svc.example.com. 7200  IN HTTPS 1 . alpn=h2,h2 oblivious

oblivious-svc.example.com. 7200  IN HTTPS 1 . (
    mandatory=oblivious oblivious )

_dns.resolver.arpa  7200  IN SVCB 1 doh.example.net (
     alpn=h2 dohpath=/dns-query{?dns} oblivious )

4. Configuration Well-Known URI

Clients that know a service is available as an oblivious target, e.g., either via discovery through the "oblivious" parameter in a SVCB or HTTPS record, or by configuration, need to know the key configuration before sending oblivious requests.¶

This document defines a well-known URI [RFC8615], "oblivious-configs", that allows a target to host its configurations.¶

The URI is constructed using the TargetName in the associated ServiceMode SVCB record.¶

For example, the URI for the following record:¶

svc.example.com. 7200  IN HTTPS 1 . alpn=h2,h2 oblivious

would be "https://svc.example.com/.well-known/oblivious-configs".¶

As another example, the URI for the following record:¶

_dns.resolver.arpa  7200  IN SVCB 1 doh.example.net (
     alpn=h2 dohpath=/dns-query{?dns} oblivious )

would be "https://doh.example.net/.well-known/oblivious-configs".¶

The content of this resource is expected to be "application/ohttp-keys", as defined in [OHTTP].¶

Before being able to use a server as an oblivious target, clients need to use this URI to fetch the configuration. They can either fetch it directly, or do so via a proxy in order to avoid the server discovering information about the client's identity. See Section 5 for more discussion of avoiding key targeting attacks.¶

5. Security and Privacy Considerations

Attackers on a network can remove SVCB information from cleartext DNS answers that are not protected by DNSSEC [DNSSEC]. This can effectively downgrade clients. However, since SVCB indications for oblivious support are just hints, a client can mitigate this by always checking for oblivious target information. Use of encrypted DNS or DNSSEC also can be used as mitigations.¶

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 well as the Security Considerations of [I-D.ietf-add-svcb-dns].¶

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 targeting 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 targeting attack. Oblivious targets that are detected to use targeted key configurations per-client MUST NOT be used.¶

When clients fetch a target's configuration using the well-known URI, they can expose their identity in the form of an IP addres if they do not connect via a proxy or some other IP-hiding mechanism. Clients SHOULD use a proxy or similar mechanism to avoid exposing client IPs to a target.¶

6. IANA Considerations

Authors' Addresses