Using DNSSEC Authentication of Named Entities (DANE) with DNS Service Bindings (SVCB) and QUIC

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 25 April 2024.¶

Copyright Notice

Copyright (c) 2023 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

The DNS-Based Authentication of Named Entities specification [RFC7671] 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, [RFC7672] describes how DANE interacts with MX records, and [RFC7673] describes its interaction with SRV records.¶

This document describes the interaction of DANE with indirection via Service Bindings [SVCB], 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.¶

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

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

3. Using DANE with Service Bindings (SVCB)

Section 6 of [RFC7671] 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 Section 4.1 of [RFC6698].¶

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 Section 7 of [RFC7671]. 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 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 Section 3 of [SVCB]), it MUST use the standard DANE logic described in Section 4.1 of [RFC6698] when falling back to non-SVCB connection.¶

4. Adding a TLSA protocol prefix for QUIC

Section 3 of [RFC6698] 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 [RFC9000], 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 [RFC8446]), "udp" (DTLS [RFC9147]), "sctp" (TLS over SCTP [RFC3436]), and "quic" (QUIC [RFC9000]).¶

5. Operational considerations

alias.example.                  HTTPS 0 xyz.provider.example.
www.alias.example.              CNAME xyz.provider.example.
xyz.provider.example.           HTTPS 1 . alpn=h2 ...
xyz.provider.example.           A     192.0.2.1
_443._tcp.xyz.provider.example. TLSA  ...

_dns.dns.example. HTTPS 1 xyz.provider.example. ( alpn=h2 ...
                                                  dohpath=/doh{?dns} )

_443._tcp.xyz.provider.example. CNAME dane-central.provider.example.
dane-central.provider.example.  TLSA  ...

6. 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 Section 4.3 of [RFC4035]), 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 [I-D.barnes-dane-uks-00]. When using a vulnerable protocol with DANE, clients MUST NOT perform any action that modifies persistent server state. (HTTP/1.1 and later and encrypted DNS are not vulnerable to UKS attacks; see Appendix A.)¶

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

api.example.com. HTTPS 1 .

api.example.com.     HTTPS 0 svc4.example.net.
svc4.example.net.    HTTPS 0 xyz.cdn.example.
xyz.cdn.example.     A     192.0.2.1

www.example.com.  CNAME api.example.com.
api.example.com.  HTTPS 1 svc4.example.net alpn=h2,h3 port=8443
svc4.example.net. CNAME xyz.cdn.example.

_dns.dns.example.com. SVCB 1 dns.my-dns-host.example. alpn=dot

_dns.dns.example.com.     SVCB 0 dns.my-dns-host.example.
dns.my-dns-host.example.  SVCB 1 . alpn=doq

_8443._foo.api.example.com. SVCB 1 api.example.com.

_8443._foo.api.example.com. SVCB 0 svc4.example.net.
svc4.example.net.           SVCB 1 .
svc4.example.net.           A    192.0.2.1

_8443._foo.api.example.com. SVCB 0 svc4.example.net.
svc4.example.net. SVCB 3 . alpn=foo,bar port=8004

8. IANA Considerations

IANA is requested to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry ([RFC8552], Section 4):¶

Appendix A. Unknown Key-Share Attacks

When using DANE, a client is vulnerable to an Unknown Key-Share (UKS) attack if it sends a command that can result in a persistent change in server-side state, using a protocol that does not confirm the server's identity. This section analyzes the vulnerability of some popular protocols to this attack, and indicates any resulting restrictions on their use:¶

• HTTP/0.9 and HTTP/1.0: Vulnerable¶

  • Clients MUST only use safe methods such as GET and HEAD.¶

  • Use of these protocol versions with DANE is NOT RECOMMENDED.¶

• HTTP/1.1 and later: Not Vulnerable¶

  • The CONNECT method ([RFC9110], Section 3.6) does not create a persistent change in server state.¶

  • All other methods are defended from misdirection attacks by server verification of the Host or :authority header ([RFC9110], Section 7.4).¶

• DNS over TLS, DTLS, or QUIC [RFC7858][RFC8094][RFC9250]: Not Vulnerable¶

  • The QUERY, STATUS, and NOTIFY OpCodes do not create a persistent change in server state.¶

  • The UPDATE OpCode does not rely on TLS for authentication.¶

Acknowledgments

TODO acknowledge.¶

Authors' Addresses