]> Meta Platforms, Inc.

ietf@bemasc.net

Google LLC

evansr@google.com

ops dnsop Internet-Draft Service Binding (SVCB) records introduce a new form of name indirection in DNS. They also convey information about the endpoint's supported protocols, such as whether QUIC transport is available. This document specifies how DNS-Based Authentication of Named Entities (DANE) interacts with Service Bindings to secure connections, including use of port numbers and transport protocols discovered via SVCB queries. The "_quic" transport name label is introduced to distinguish TLSA records for DTLS and QUIC. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction The DNS-Based Authentication of Named Entities specification explains how clients locate the TLSA record for a service of interest, starting with knowledge of the service's hostname, transport, and port number. These are concatenated, forming a name like _8080._tcp.example.com. It also specifies how clients should locate the TLSA records when one or more CNAME records are present, aliasing either the hostname or the initial TLSA query name, and the resulting server names used in TLS or DTLS. There are various DNS records other than CNAME that add indirection to the host resolution process, requiring similar specifications. Thus, describes how DANE interacts with MX records, and describes its interaction with SRV records. This document describes the interaction of DANE with indirection via Service Bindings , i.e. SVCB-compatible records such as SVCB and HTTPS. It also explains how to use DANE with new TLS-based transports such as QUIC.

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 when, and only when, they appear in all capitals, as shown here. The contents of this document apply equally to all SVCB-compatible record types, such as SVCB and HTTPS records. For brevity, the abbrevation "SVCB" is used to refer to these record types generally.

Using DANE with Service Bindings (SVCB) says:

• With protocols that support explicit transport redirection via DNS MX records, SRV records, or other similar records, the TLSA base domain is based on the redirected transport endpoint rather than the origin domain.

This document applies the same logic to SVCB-compatible records. Specifically, if SVCB resolution was entirely secure (including any AliasMode records and/or CNAMEs), then for each connection attempt derived from a SVCB-compatible record,

• The initial TLSA base domain MUST be the final SVCB TargetName used for this connection attempt. (Names appearing earlier in a resolution chain are not used.)
• The transport prefix MUST be the transport of this connection attempt (possibly influenced by the "alpn" SvcParam).
• The port prefix MUST be the port number of this connection attempt (possibly influenced by the "port" SvcParam).

Resolution security is assessed according to the criteria in . If the initial TLSA base domain is the start of a secure CNAME chain, clients MUST first try to use the end of the chain as the TLSA base domain, with fallback to the initial base domain, as described in . However, domain owners SHOULD NOT place a CNAME record on a SVCB TargetName, as this arrangement is unusual, inefficient, and at risk for deprecation in a future revision. If any TLSA QNAME is aliased by a CNAME, clients MUST follow the TLSA CNAME to complete the resolution of the TLSA records. (This does not alter the TLSA base domain.) If a TLSA RRSet is securely resolved, the client MUST set the SNI to the TLSA base domain of the RRSet. In usage modes other than DANE-EE(3), the client MUST validate that the certificate covers this base domain, and MUST NOT require it to cover any other domain. If the client has SVCB-optional behavior (as defined in ), it MUST use the standard DANE logic described in when falling back to non-SVCB connection.

Adding a TLSA protocol prefix for QUIC defines the protocol prefix used for constructing TLSA QNAMEs, and says:

• The transport names defined for this protocol are "tcp", "udp", and "sctp".

When this text was written, there was exactly one TLS-based protocol defined for each of these transports. However, with the introduction of QUIC , there are now multiple TLS-derived protocols that can operate over UDP, even on the same port. To distinguish the availability and configuration of DTLS and QUIC, this document updates the above sentence as follows:

• The transport names defined for this protocol are "tcp" (TLS over TCP ), "udp" (DTLS ), "sctp" (TLS over SCTP ), and "quic" (QUIC ).

Operational considerations

Recommended configurations Service consumers are expected to use a CNAME or SVCB AliasMode record to point at provider-controlled records when possible, e.g.: If the service needs its own SvcParamKeys, it cannot use CNAME or AliasMode, so it publishes its own SVCB ServiceMode record with SvcParams that are compatible with the provider, e.g.: For ease of management, providers may want to alias various TLSA QNAMEs to a single RRSet: Any DANE certificate usage mode is compatible with SVCB, but the usage guidelines from continue to apply.

Unintended pinning As noted in , DANE encounters operational difficulties when the TLSA RRset is published by an entity other than the service provider. For example, a customer might copy the TLSA records into their own zone, rather than publishing an alias to the TLSA RRset hosted in the service provider's zone. When the service subsequently rotates its TLS keys, DANE authentication will fail, resulting in an outage for this customer. Accordingly, zone owners MUST NOT publish TLSA records for public keys that are not under their control unless they have an explicit arrangement with the key holder. To prevent the above misconfiguration and ensure that TLS keys can be rotated freely, service operators MAY reject TLS connections whose SNI does not correspond to an approved TLSA base domain. Service Bindings also enable any third party consumer to publish fixed SvcParams for the service. This can cause an outage or service degradation if the service makes a backward-incompatible configuration change. Accordingly, zone owners should avoid publishing SvcParams for a TargetName that they do not control, and service operators should exercise caution when making incompatible configuration changes.

Security Considerations The use of TLSA records specified in this document is independent for each SVCB connection attempt. In environments where DANE is optional, this means that the client might use DANE for some connection attempts but not others when processing a single SVCB RRSet. This document only specifies the use of TLSA records when all relevant DNS records (including SVCB, TLSA, and CNAME records) were resolved securely. If any of these resolutions were insecure (as defined in ), the client MUST NOT rely on the TLSA record for connection security. However, if the client would otherwise have used an insecure plaintext transport, it MAY use an insecure resolution result to achieve opportunistic security. Certain protocols that can run over TLS, such as HTTP/1.0, do not confirm the name of the service after connecting. With DANE, these protocols are subject to an Unknown Key Share (UKS) attack, in which the client believes it is connecting to the attacker's domain, but is actually connecting to an unaffiliated victim domain . Clients SHOULD NOT use DANE with vulnerable protocols. (HTTP/1.1 and later and encrypted DNS are not normally vulnerable to UKS attacks, but see for some important exceptions.)

Examples The following examples demonstrate Service Binding interaction with TLSA base domain selection. All of the RRSets below are assumed fully-secure with all related DNSSEC record types omitted for brevity.

HTTPS ServiceMode Given service URI https://api.example.com and record: The TLSA QNAME is _443._tcp.api.example.com.

HTTPS AliasMode Given service URI https://api.example.com and records: The TLSA QNAME is _443._tcp.xyz.cdn.example.

QUIC and CNAME Given service URI https://www.example.com and records: If the connection attempt is using HTTP/3, the transport label is set to _quic; otherwise _tcp is used. The initial TLSA QNAME would be one of:

• _8443._quic.xyz.cdn.example
• _8443._tcp.xyz.cdn.example

If no TLSA record is found, the fallback TLSA QNAME would be one of:

• _8443._quic.svc4.example.net
• _8443._tcp.svc4.example.net

DNS ServiceMode Given a DNS server dns.example.com and record: The TLSA QNAME is _853._tcp.dns.my-dns-host.example. The port and protocol are inferred from the "dot" ALPN value.

DNS AliasMode Given a DNS server dns.example.com and records: The TLSA QNAME is _853._quic.dns.my-dns-host.example. The port and protocol are inferred from the "doq" ALPN value.

New scheme ServiceMode Given service URI foo://api.example.com:8443 and record: The TLSA QNAME is _8443._$PROTO.api.example.com, where $PROTO is the appropriate value for the client-selected transport as discussed in .

New scheme AliasMode Given service URI foo://api.example.com:8443 and records: The TLSA QNAME is _8443._$PROTO.svc4.example.net (with $PROTO as above). This is the same if the ServiceMode record is absent.

New protocols Given service URI foo://api.example.com:8443 and records: The TLSA QNAME is _8004._$PROTO1.svc4.example.net or _8004._$PROTO2.svc4.example.net, where $PROTO1 and $PROTO2 are the transport prefixes appropriate for "foo" and "bar" respectively. (Note that SVCB requires each ALPN to unambiguously indicate a transport.)

IANA Considerations IANA is requested to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry ():

RR Type	_NODE NAME	Reference
TLSA	_quic	(This document)

References Normative References This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records. Google Akamai Technologies Akamai Technologies This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309. The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance. Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Informative References This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). The DNS-Based Authentication of Named Entities (DANE) specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its Transport Layer Security (TLS) certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers). However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain name cannot apply the rules from RFC 6698. Therefore, this document provides guidelines that enable such protocols to locate and use TLSA records. Mozilla Mozilla Mozilla Unknown key-share attacks are a class of attacks that allow an attacker to deceive one peer of a secure communication as to the identity of the remote peer. When used with traditional, PKI-based authentication, TLS-based applications are generally safe from unknown key-share attacks. DNS-based Authentication of Named Entities (DANE), however, proposes that applications perform a different set of checks as part of authenticating a TLS connection. As a result, DANE as currently specified is likely to lead to unknown key-share attacks when clients support DANE for authentication. We describe these risks and some simple mitigations. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect. This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies the use of TLS, rather than cleartext, to prevent zone content collection via passive monitoring of zone transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995 and RFC 5936 with respect to efficient use of TCP connections and RFC 7766 with respect to the recommended number of connections between a client and server for each transport.

Unknown Key-Share Attacks In the Unknown Key-Share (UKS) Attack , a hostile domain ("attacker.example") claims the IP addresses and TLSA records of another domain ("victim.example"). A client who attempts to connect to "attacker.example" will actually be connecting to "victim.example". The client then sends some commands or requests over this connection. If the server rejects these requests, or if the attacker could have forwarded these requests itself, the attack confers no advantage. However, if the client issues commands that the attacker could not have issued, and the victim does not ignore these requests, then the attack could change state at the victim server, reveal confidential information to the attacker (e.g., via same-origin data sharing in the client), or waste resources. Here are some examples of requests that the attacker likely could not have issued themselves:

• Requests authenticated using a TLS Client Certificate or other credential that is bound to the connection but not the domain.
• Requests that are only permitted if they appear to come from a particular IP range.

This section lists some protocols that can be used with SVCB, analyzes their vulnerability to this attack, and indicates any resulting restrictions on their use:

• HTTP/0.9 and HTTP/1.0: Vulnerable
  • Clients MUST NOT use TLS Client Authentication with DANE and these protocol versions.
    • Example attack: "https://attacker.example/" fetches "/profile" in Javascript. The second request is directed to "victim.example" and authenticated by a client certificate, revealing the user's profile to the attacker.
  • Use of these protocol versions with DANE is NOT RECOMMENDED.
• HTTP/1.1 and later: Slightly Vulnerable
  • The CONNECT method () MUST NOT be used on a connection authenticated with DANE.
    • Example attack: "attacker.example" advertises a CONNECT proxy service to existing customers of the "victim.example" proxy, which is access-controlled by client IP. To reduce its own operating costs, "attacker.example" uses UKS to send users back to "victim.example", resulting in the attacker's service appearing to work but silently consuming clients' transfer quota on "victim.example".
  • Clients MAY use all other methods with DANE, including Extended CONNECT . These methods are defended from misdirection attacks by server verification of the Host or :authority header ().
• DNS over TLS, DTLS, or QUIC :
  • For resolution: Not Vulnerable
    • DNS resolution does not change state at the server, reveal confidential information to the attacker, or waste significant resources.
  • For other uses: Mitigation Required
    • When using DNS for other purposes such as zone transfers , clients relying on DANE for server authentication MUST NOT use a client certificate that is authorized by multiple potentially hostile servers.

Acknowledgments TODO acknowledge.