< draft-ietf-add-svcb-dns-01.txt   draft-ietf-add-svcb-dns-02.txt >
add B. Schwartz add B. Schwartz
Internet-Draft Google LLC Internet-Draft Google LLC
Intended status: Standards Track 21 October 2021 Intended status: Standards Track 1 February 2022
Expires: 24 April 2022 Expires: 5 August 2022
Service Binding Mapping for DNS Servers Service Binding Mapping for DNS Servers
draft-ietf-add-svcb-dns-01 draft-ietf-add-svcb-dns-02
Abstract Abstract
The SVCB DNS record type expresses a bound collection of endpoint The SVCB DNS record type expresses a bound collection of endpoint
metadata, for use when establishing a connection to a named service. metadata, for use when establishing a connection to a named service.
DNS itself can be such a service, when the server is identified by a DNS itself can be such a service, when the server is identified by a
domain name. This document provides the SVCB mapping for named DNS domain name. This document provides the SVCB mapping for named DNS
servers, allowing them to indicate support for new transport servers, allowing them to indicate support for new transport
protocols. protocols.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 April 2022. This Internet-Draft will expire on 5 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Identities and Names . . . . . . . . . . . . . . . . . . . . 3 3. Identities and Names . . . . . . . . . . . . . . . . . . . . 3
3.1. Special case: non-default ports . . . . . . . . . . . . . 3 3.1. Special case: non-default ports . . . . . . . . . . . . . 4
4. Applicable existing SvcParamKeys . . . . . . . . . . . . . . 4 4. Applicable existing SvcParamKeys . . . . . . . . . . . . . . 4
4.1. alpn . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. alpn . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. port . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. port . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Other applicable SvcParamKeys . . . . . . . . . . . . . . 4 4.3. Other applicable SvcParamKeys . . . . . . . . . . . . . . 5
5. New SvcParamKeys . . . . . . . . . . . . . . . . . . . . . . 5 5. New SvcParamKeys . . . . . . . . . . . . . . . . . . . . . . 5
5.1. dohpath . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. dohpath . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8.1. Adversary on the query path . . . . . . . . . . . . . . . 6 8.1. Adversary on the query path . . . . . . . . . . . . . . . 7
8.2. Adversary on the transport path . . . . . . . . . . . . . 7 8.1.1. Downgrade attacks . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8.1.2. Redirection attacks . . . . . . . . . . . . . . . . . 7
8.2. Adversary on the transport path . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Mapping Summary . . . . . . . . . . . . . . . . . . 9 Appendix A. Mapping Summary . . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The SVCB record type [SVCB] provides clients with information about The SVCB record type [SVCB] provides clients with information about
how to reach alternative endpoints for a service, which may have how to reach alternative endpoints for a service, which may have
improved performance or privacy properties. The service is improved performance or privacy properties. The service is
identified by a "scheme" indicating the service type, a hostname, and identified by a "scheme" indicating the service type, a hostname, and
optionally other information such as a port number. A DNS server is optionally other information such as a port number. A DNS server is
skipping to change at page 4, line 36 skipping to change at page 4, line 47
resulting HTTP connection. resulting HTTP connection.
If the protocol set contains protocols with different default ports, If the protocol set contains protocols with different default ports,
and no port key is specified, then protocols are contacted separately and no port key is specified, then protocols are contacted separately
on their default ports. Note that in this configuration, ALPN on their default ports. Note that in this configuration, ALPN
negotiation does not defend against cross-protocol downgrade attacks. negotiation does not defend against cross-protocol downgrade attacks.
4.2. port 4.2. port
This key is used to indicate the target port for connection This key is used to indicate the target port for connection
((Section 6.2 of [SVCB])). If omitted, the client SHALL use the (Section 6.2 of [SVCB]). If omitted, the client SHALL use the
default port for each transport protocol (853 for DNS over TLS [DOT], default port for each transport protocol (853 for DNS over TLS [DOT],
443 for DNS over HTTPS). 443 for DNS over HTTPS).
This key is automatically mandatory if present. (See Section 7 of This key is automatically mandatory if present. (See Section 7 of
[SVCB] for the definition of "automatically mandatory".) [SVCB] for the definition of "automatically mandatory".)
4.3. Other applicable SvcParamKeys 4.3. Other applicable SvcParamKeys
These SvcParamKeys from [SVCB] apply to the "dns" scheme without These SvcParamKeys from [SVCB] apply to the "dns" scheme without
modification: modification:
skipping to change at page 6, line 7 skipping to change at page 6, line 15
6. Limitations 6. Limitations
This document is concerned exclusively with the DNS transport, and This document is concerned exclusively with the DNS transport, and
does not affect or inform the construction or interpretation of DNS does not affect or inform the construction or interpretation of DNS
messages. For example, nothing in this document indicates whether messages. For example, nothing in this document indicates whether
the service is intended for use as a recursive or authoritative DNS the service is intended for use as a recursive or authoritative DNS
server. Clients must know the intended use in their context. server. Clients must know the intended use in their context.
7. Examples 7. Examples
* A resolver at "simple.example" that supports DNS over TLS on port * A resolver at "simple.example" that supports DNS over TLS on port
853 (implicitly, as this is its default port): 853 (implicitly, as this is its default port):
_dns.simple.example. 7200 IN SVCB 1 simple.example. alpn=dot _dns.simple.example. 7200 IN SVCB 1 simple.example. alpn=dot
* A resolver at "doh.example" that supports only DNS over HTTPS (DNS * A resolver at "doh.example" that supports only DNS over HTTPS (DNS
over TLS is not supported): over TLS is not supported):
_dns.doh.example. 7200 IN SVCB 1 doh.example. ( _dns.doh.example. 7200 IN SVCB 1 doh.example. (
alpn=h2 dohpath=/dns-query{?dns} ) alpn=h2 dohpath=/dns-query{?dns} )
* A resolver at "resolver.example" that supports: * A resolver at "resolver.example" that supports:
- DNS over TLS on "resolver.example" ports 853 (implicit in - DNS over TLS on "resolver.example" ports 853 (implicit in
record 1) and 8530 (explicit in record 2), with record 1) and 8530 (explicit in record 2), with
"resolver.example" as the Authentication Domain Name, "resolver.example" as the Authentication Domain Name,
- DNS over HTTPS at https://resolver.example/dns-query{?dns} - DNS over HTTPS at https://resolver.example/dns-query{?dns}
(record 1), and (record 1), and
- an experimental protocol on fooexp.resolver.example:5353 - an experimental protocol on fooexp.resolver.example:5353
(record 3): (record 3):
_dns.resolver.example. 7200 IN SVCB 1 resolver.example. ( _dns.resolver.example. 7200 IN SVCB 1 resolver.example. (
alpn=dot,h2,h3 dohpath=/dns-query{?dns} ) alpn=dot,h2,h3 dohpath=/dns-query{?dns} )
_dns.resolver.example. 7200 IN SVCB 2 resolver.example. alpn=dot port=8530 _dns.resolver.example. 7200 IN SVCB 2 resolver.example. (
_dns.resolver.example. 7200 IN SVCB 3 fooexp port=5353 alpn=foo foo-info=... alpn=dot port=8530 )
_dns.resolver.example. 7200 IN SVCB 3 fooexp (
port=5353 alpn=foo foo-info=... )
* A nameserver at "ns.example" whose service configuration is * A nameserver at "ns.example" whose service configuration is
published on a different domain: published on a different domain:
_dns.ns.example. 7200 IN SVCB 0 _dns.ns.nic.example. _dns.ns.example. 7200 IN SVCB 0 _dns.ns.nic.example.
8. Security Considerations 8. Security Considerations
8.1. Adversary on the query path 8.1. Adversary on the query path
This section considers an adversary who can add or remove responses This section considers an adversary who can add or remove responses
to the SVCB query. to the SVCB query.
During secure transport establishment, clients MUST authenticate the During secure transport establishment, clients MUST authenticate the
server to its authentication name, which is not influenced by the server to its authentication name, which is not influenced by the
SVCB record contents. Accordingly, this draft does not mandate the SVCB record contents. Accordingly, this draft does not mandate the
use of DNSSEC. This draft also does not specify how clients use of DNSSEC. This draft also does not specify how clients
authenticate the name (e.g. selection of roots of trust), which might authenticate the name (e.g. selection of roots of trust), which might
vary according to the context. vary according to the context.
Although this adversary cannot alter the authentication name of the 8.1.1. Downgrade attacks
service, it does have control of the port number and "dohpath" value.
As a result, the adversary can direct DNS queries for $HOSTNAME to This attacker cannot impersonate the secure endpoint, but it can
any port on $HOSTNAME, and any path on "https://$HOSTNAME", even if forge a response indicating that the requested SVCB records do not
$HOSTNAME is not actually a DNS server. If the DNS client uses exist. For a SVCB-reliant client ([SVCB], Section 3) this only
shared TLS or HTTP state, the client could be correctly authenticated results in a denial of service. However, SVCB-optional clients will
(e.g. using a TLS client certificate or HTTP cookie). generally fall back to insecure DNS in this case, exposing all DNS
traffic to attacks.
8.1.2. Redirection attacks
SVCB-reliant clients always enforce the authentication domain name,
but they are still subject to attacks using the transport, port
number, and "dohpath" value, which are controlled by this adversary.
By changing these values in the SVCB answers, the adversary can
direct DNS queries for $HOSTNAME to any port on $HOSTNAME, and any
path on "https://$HOSTNAME". If the DNS client uses shared TLS or
HTTP state, the client could be correctly authenticated (e.g. using a
TLS client certificate or HTTP cookie).
This behavior creates a number of possible attacks for certain server This behavior creates a number of possible attacks for certain server
configurations. For example, if "https://$HOSTNAME/upload" accepts configurations. For example, if "https://$HOSTNAME/upload" accepts
any POST request as a public file upload, the adversary could forge a any POST request as a public file upload, the adversary could forge a
SVCB record containing dohpath=/upload. This would cause the client SVCB record containing dohpath=/upload. This would cause the client
to upload and publish every query, resulting in unexpected storage to upload and publish every query, resulting in unexpected storage
costs for the server and privacy loss for the client. costs for the server and privacy loss for the client. Similarly, if
two DoH endpoints are available on the same origin, and the service
has designated one of them for use with this specification, this
adversary can cause clients to use the other endpoint instead.
To mitigate this attack, a client of this SVCB mapping MUST NOT To mitigate redirection attacks, a client of this SVCB mapping MUST
provide client authentication for DNS queries, except to servers that NOT provide client authentication for DNS queries, except to servers
it specifically knows are not vulnerable to such attacks, and a DoH that it specifically knows are not vulnerable to such attacks. If an
service operator MUST ensure that all unauthenticated DoH requests to endpoint sends an invalid response to a DNS query, the client SHOULD
its origin maintain the DoH service's privacy guarantees, regardless NOT send more queries to that endpoint. DNS services that are
of the path. Also, if an alternative service endpoint sends an identified by a hostname (Section 3) MUST ensure that all
invalid response to a DNS query, the client SHOULD NOT send more unauthenticated DNS requests to that name receive any promised
queries to that endpoint. privacy and security guarantees, regardless of transport, port
number, or HTTP path.
8.2. Adversary on the transport path 8.2. Adversary on the transport path
This section considers an adversary who can modify network traffic This section considers an adversary who can modify network traffic
between the client and the alternative service (identified by the between the client and the alternative service (identified by the
TargetName). TargetName).
For a SVCB-reliant client ([SVCB] Section 3), this adversary can only For a SVCB-reliant client, this adversary can only cause a denial of
cause a denial of service. However, because DNS is unencrypted by service. However, because DNS is unencrypted by default, this
default, this adversary can execute a downgrade attack against SVCB- adversary can execute a downgrade attack against SVCB-optional
optional clients. Accordingly, when use of this specification is clients. Accordingly, when use of this specification is optional,
optional, clients SHOULD switch to SVCB-reliant behavior if SVCB clients SHOULD switch to SVCB-reliant behavior if SVCB resolution
resolution succeeds. Specifications making using of this mapping MAY succeeds. Specifications making using of this mapping MAY adjust
adjust this fallback behavior to suit their requirements. this fallback behavior to suit their requirements.
9. IANA Considerations 9. IANA Considerations
Per [SVCB] IANA would be directed to add the following entry to the Per [SVCB] IANA is directed to add the following entry to the SVCB
SVCB Service Parameters registry. Service Parameters registry.
+========+=========+==============================+=================+ +========+=========+==============================+=================+
| Number | Name | Meaning | Reference | | Number | Name | Meaning | Reference |
+========+=========+==============================+=================+ +========+=========+==============================+=================+
| 7 | dohpath | DNS over HTTPS path template | (This | | 7 | dohpath | DNS over HTTPS path template | (This |
| | | | document) | | | | | document) |
+--------+---------+------------------------------+-----------------+ +--------+---------+------------------------------+-----------------+
Table 1 Table 1
Per [Attrleaf], IANA would be directed to add the following entry to Per [Attrleaf], IANA is directed to add the following entry to the
the DNS Underscore Global Scoped Entry Registry: DNS Underscore Global Scoped Entry Registry:
+=========+============+===============+=================+ +=========+============+===============+=================+
| RR TYPE | _NODE NAME | Meaning | Reference | | RR TYPE | _NODE NAME | Meaning | Reference |
+=========+============+===============+=================+ +=========+============+===============+=================+
| SVCB | _dns | DNS SVCB info | (This document) | | SVCB | _dns | DNS SVCB info | (This document) |
+---------+------------+---------------+-----------------+ +---------+------------+---------------+-----------------+
Table 2 Table 2
10. References 10. References
 End of changes. 29 change blocks. 
67 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/