Oblivious HTTP Application Intermediation                       T. Pauly
Internet-Draft                                                Apple Inc.
Intended status: Informational                                  T. Reddy
Expires: 26 November 2022                                         Akamai
                                                             25 May 2022


      Discovery of Oblivious Services via Service Binding Records
                    draft-pauly-ohai-svcb-config-01

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, as well as a mechanism to look up oblivious
   key configurations using a well-known URI.

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






Pauly & Reddy           Expires 26 November 2022                [Page 1]


Internet-Draft         Oblivious Services in SVCB               May 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 oblivious SvcParamKey . . . . . . . . . . . . . . . . . .   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
   4.  Configuration Well-Known URI  . . . . . . . . . . . . . . . .   5
   5.  Security and Privacy Considerations . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  SVCB Service Parameter  . . . . . . . . . . . . . . . . .   7
     6.2.  Well-Known URI  . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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



Pauly & Reddy           Expires 26 November 2022                [Page 2]


Internet-Draft         Oblivious Services in SVCB               May 2022


   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.




Pauly & Reddy           Expires 26 November 2022                [Page 3]


Internet-Draft         Oblivious Services in SVCB               May 2022


   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.

3.1.  Use in HTTPS service records

   For the "https" scheme, which uses the HTTPS RR type instead of SVCB,
   the presence of the "oblivious" parameter means that the service
   being described is an Oblivious HTTP service that uses the default
   "message/bhttp" media type [OHTTP] [BINARY-HTTP].

   For example, an HTTPS service record for svc.example.com that
   supports an oblivious target could look like this:

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

   A similar record for a service that only support oblivious
   connectivity could look like this:

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

3.2.  Use in DNS server SVCB records

   For the "dns" scheme, as defined in [DNS-SVCB], the presence of the
   "oblivious" 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].

   In order for DNS servers to function as oblivious targets, they need
   to be accessible via an oblivious proxy.  Encrypted DNS servers used
   with the discovery mechanisms described in this section can either be
   publicly accessible, or specific to a network.  In general, only
   publicly accessible DNS servers will work as Oblivious DNS servers,
   unless there is a coordinated deployment with an oblivious proxy that
   is also hosted within a network.

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

   For example, a DoH service advertised over DDR can be annotated as
   supporting oblivious resolution using the following record:



Pauly & Reddy           Expires 26 November 2022                [Page 4]


Internet-Draft         Oblivious Services in SVCB               May 2022


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

   Clients still need to perform some verification of oblivious DNS
   servers, such as the TLS certificate check described in [DDR].  This
   certificate check can be done when looking up the configuration on
   the resolver using the well-known URI (Section 4), which can either
   be done directly, or via a proxy to avoid exposing client IP
   addresses.

   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.

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:





Pauly & Reddy           Expires 26 November 2022                [Page 5]


Internet-Draft         Oblivious Services in SVCB               May 2022


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



Pauly & Reddy           Expires 26 November 2022                [Page 6]


Internet-Draft         Oblivious Services in SVCB               May 2022


6.  IANA Considerations

6.1.  SVCB Service Parameter

   IANA is requested to add the following entry to the SVCB Service
   Parameters registry ([SVCB]).

       +========+===========+=========================+===========+
       | Number | Name      | Meaning                 | Reference |
       +========+===========+=========================+===========+
       | TBD    | oblivious | Describes if a service  | (This     |
       |        |           | has an oblivious target | document) |
       +--------+-----------+-------------------------+-----------+

                                 Table 1

6.2.  Well-Known URI

   IANA is requested to add a new entry in the "Well-Known URIs"
   registry [RFC8615] with the following information:

   URI suffix: oblivious-configs

   Change controller: IETF

   Specification document: This document

   Status: permanent

   Related information: N/A

7.  References

7.1.  Normative References

   [BINARY-HTTP]
              Thomson, M. and C. A. Wood, "Binary Representation of HTTP
              Messages", Work in Progress, Internet-Draft, draft-ietf-
              httpbis-binary-message-04, 23 May 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
              binary-message-04>.

   [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-06, 4 April
              2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
              add-ddr-06>.




Pauly & Reddy           Expires 26 November 2022                [Page 7]


Internet-Draft         Oblivious Services in SVCB               May 2022


   [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-07, 13 April
              2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
              add-dnr-07>.

   [DNS-SVCB] Schwartz, B., "Service Binding Mapping for DNS Servers",
              Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns-
              03, 22 April 2022, <https://datatracker.ietf.org/doc/html/
              draft-ietf-add-svcb-dns-03>.

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

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8615>.

   [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-10, 24 May 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
              svcb-https-10>.

7.2.  Informative References









Pauly & Reddy           Expires 26 November 2022                [Page 8]


Internet-Draft         Oblivious Services in SVCB               May 2022


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

   [I-D.ietf-add-svcb-dns]
              Schwartz, B., "Service Binding Mapping for DNS Servers",
              Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns-
              03, 22 April 2022, <https://datatracker.ietf.org/doc/html/
              draft-ietf-add-svcb-dns-03>.

Authors' Addresses

   Tommy Pauly
   Apple Inc.
   Email: tpauly@apple.com


   Tirumaleswar Reddy
   Akamai
   Email: kondtir@gmail.com























Pauly & Reddy           Expires 26 November 2022                [Page 9]