]> Meta Platforms, Inc.

ietf@bemasc.net

Google LLC

evansr@google.com

ops dnsop Internet-Draft Service Binding records introduce a new form of name indirection in DNS. This document specifies DNS-Based Authentication of Named Entities (DANE) interaction with Service Bindings to secure endpoints including use of ports and transports discovered via Service Parameters. 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 record when one or more CNAME records are present, aliasing either the hostname or the TLSA record's name, and the resulting server names used in TLS. 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 draft 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.

Using DANE with Service Bindings 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 draft 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).

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 . If any TLSA QNAME is aliased by a CNAME, clients MUST follow the TLSA CNAME to complete the resolution of the TLSA record. (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.

Updating the TLSA protocol prefixes defined the protocol prefix used for constructing TLSA QNAMEs, and said:

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

At that time, 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 draft 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 CNAME or SVCB AliasMode to point at provider-controlled records, e.g.: ]]> For ease of management, providers may want to alias various TLSA QNAMEs to a single RRSet: ]]>

Accidental pinning When a service is used by third-party consumers, DANE allows the consumer to publish records that make claims about the certificates used by the service. When the service subsequently rotates its TLS keys, DANE authentication will fail for these consumers, resulting in an outage. 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 prevents 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 NOT publish SvcParams for a TargetName that they do not control, and service operators should take caution when making incompatible configuration changes.

Security Considerations This document specifies the use of TLSA as a property of each connection attempt. In environments where DANE is optional, this means that the fallback procedure might use DANE for some conection attempts but not others. This document only specifies the use of TLSA records when the SVCB records were resolved securely. Use of TLSA records in conjunction with insecurely resolved SVCB records is not safe in general, although there may be some configurations where it is appropriate (e.g. when only opportunistic security is available).

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.example-cdn.com.

QUIC and CNAME Given service URI https://api.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.example-cdn.com
• _8443._tcp.xyz.example-cdn.com

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

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

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

DNS ServiceMode Given a DNS server dns.example.com and record: The TLSA QNAME is _853._tcp.dns.example.com. The TLSA base name is taken from the SVCB TargetName. The port and protocol are taken from the "dot" ALPN value.

DNS AliasMode Given a DNS server dns.example.com and records: The TLSA QNAME is _853._tcp.ns1.my-dns-host.net.

IANA Considerations IANA is instructed 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" 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 [HTTP]. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. 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. RTFM, Inc. Arm Limited Google, Inc. 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] 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.

Acknowledgments TODO acknowledge.