idnits 2.17.1 draft-rebs-dnsop-svcb-dane-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 13 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 December 2021) is 868 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop B.M. Schwartz 3 Internet-Draft R. Evans 4 Updates: rfc6698 (if approved) Google LLC 5 Intended status: Standards Track 9 December 2021 6 Expires: 12 June 2022 8 Using Service Bindings with DANE 9 draft-rebs-dnsop-svcb-dane-00 11 Abstract 13 Service Binding records introduce a new form of name indirection in 14 DNS. This document specifies DNS-Based Authentication of Named 15 Entities (DANE) interaction with Service Bindings to secure endpoints 16 including use of ports and transports discovered via Service 17 Parameters. 19 Discussion Venues 21 This note is to be removed before publishing as an RFC. 23 Source for this draft and an issue tracker can be found at 24 https://github.com/bemasc/svcb-dane. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 12 June 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 61 3. Using DANE with Service Bindings . . . . . . . . . . . . . . 3 62 4. Updating the TLSA protocol prefixes . . . . . . . . . . . . . 4 63 5. Operational considerations . . . . . . . . . . . . . . . . . 4 64 5.1. Recommended configurations . . . . . . . . . . . . . . . 4 65 5.2. Accidental pinning . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7.1. HTTPS ServiceMode . . . . . . . . . . . . . . . . . . . . 6 69 7.2. HTTPS AliasMode . . . . . . . . . . . . . . . . . . . . . 6 70 7.3. QUIC and CNAME . . . . . . . . . . . . . . . . . . . . . 6 71 7.4. New scheme ServiceMode . . . . . . . . . . . . . . . . . 6 72 7.5. New scheme AliasMode . . . . . . . . . . . . . . . . . . 7 73 7.6. New protocols . . . . . . . . . . . . . . . . . . . . . . 7 74 7.7. DNS ServiceMode . . . . . . . . . . . . . . . . . . . . . 7 75 7.8. DNS AliasMode . . . . . . . . . . . . . . . . . . . . . . 7 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 9.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 The DNS-Based Authentication of Named Entities specification 86 [RFC7671] explains how clients locate the TLSA record for a service 87 of interest, starting with knowledge of the service's hostname, 88 transport, and port number. These are concatenated, forming a name 89 like _8080._tcp.example.com. It also specifies how clients should 90 locate the TLSA record when one or more CNAME records are present, 91 aliasing either the hostname or the TLSA record's name, and the 92 resulting server names used in TLS. 94 There are various DNS records other than CNAME that add indirection 95 to the host resolution process, requiring similar specifications. 96 Thus, [RFC7672] describes how DANE interacts with MX records, and 97 [RFC7673] describes its interaction with SRV records. 99 This draft describes the interaction of DANE with indirection via 100 Service Bindings [SVCB], i.e. SVCB-compatible records such as SVCB 101 and HTTPS. It also explains how to use DANE with new TLS-based 102 transports such as QUIC. 104 2. Conventions and Definitions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in 109 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 3. Using DANE with Service Bindings 114 Section 6 of [RFC7671] says: 116 With protocols that support explicit transport redirection via DNS 117 MX records, SRV records, or other similar records, the TLSA base 118 domain is based on the redirected transport endpoint rather than 119 the origin domain. 121 This draft applies the same logic to SVCB-compatible records. 122 Specifically, if SVCB resolution was entirely secure (including any 123 AliasMode records and/or CNAMEs), then for each connection attempt 124 derived from a SVCB-compatible record, 126 * The initial TLSA base domain MUST be the final SVCB TargetName 127 used for this connection attempt. (Names appearing earlier in a 128 resolution chain are not used.) 130 * The transport prefix MUST be the transport of this connection 131 attempt (possibly influenced by the "alpn" SvcParam). 133 * The port prefix MUST be the port number of this connection attempt 134 (possibly influenced by the "port" SvcParam). 136 If the SVCB TargetName contains a CNAME record, clients MUST first 137 try to use the CNAME target as the TLSA base domain, with fallback to 138 the final SVCB TargetName as the TLSA base domain, as described in 139 Section 7 of [RFC7671]. 141 If any TLSA QNAME is aliased by a CNAME, clients MUST follow the TLSA 142 CNAME to complete the resolution of the TLSA record. (This does not 143 alter the TLSA base domain.) 145 If a TLSA RRSet is securely resolved, the client MUST set the SNI to 146 the TLSA base domain of the RRSet. In usage modes other than DANE- 147 EE(3), the client MUST validate that the certificate covers this base 148 domain, and MUST NOT require it to cover any other domain. 150 If the client has SVCB-optional behavior (as defined in Section 3 of 151 [SVCB]), it MUST use the standard DANE logic described in Section 4.1 152 of [RFC6698] when falling back to non-SVCB connection. 154 4. Updating the TLSA protocol prefixes 156 Section 3 of [RFC6698] defined the protocol prefix used for 157 constructing TLSA QNAMEs, and said: 159 The transport names defined for this protocol are "tcp", "udp", 160 and "sctp". 162 At that time, there was exactly one TLS-based protocol defined for 163 each of these transports. However, with the introduction of QUIC 164 [RFC9000], there are now multiple TLS-derived protocols that can 165 operate over UDP, even on the same port. To distinguish the 166 availability and configuration of DTLS and QUIC, this draft Updates 167 the above sentence as follows: 169 The transport names defined for this protocol are "tcp" (TLS over 170 TCP [RFC8446]), "udp" (DTLS [I-D.draft-ietf-tls-dtls13]), "sctp" 171 (TLS over SCTP [RFC3436]), and "quic" (QUIC [RFC9000]). 173 5. Operational considerations 175 5.1. Recommended configurations 177 Service consumers are expected to use CNAME or SVCB AliasMode to 178 point at provider-controlled records, e.g.: 180 alias.net. HTTPS 0 xyz.provider.com. 181 www.alias.net. CNAME xyz.provider.com. 182 xyz.provider.com. HTTPS 1 . alpn=h2 ... 183 xyz.provider.com. A 192.0.2.1 184 _443._tcp.xyz.provider.com. TLSA 186 For ease of management, providers may want to alias various TLSA 187 QNAMEs to a single RRSet: 189 _443._tcp.xyz.provider.com. CNAME dane-central.provider.com. 190 dane-central.provider.com. TLSA 192 5.2. Accidental pinning 194 When a service is used by third-party consumers, DANE allows the 195 consumer to publish records that make claims about the certificates 196 used by the service. When the service subsequently rotates its TLS 197 keys, DANE authentication will fail for these consumers, resulting in 198 an outage. Accordingly, zone owners MUST NOT publish TLSA records 199 for public keys that are not under their control unless they have an 200 explicit arrangement with the key holder. 202 To prevents the above misconfiguration and ensure that TLS keys can 203 be rotated freely, service operators MAY reject TLS connections whose 204 SNI does not correspond to an approved TLSA base domain. 206 Service Bindings also enable any third party consumer to publish 207 fixed SvcParams for the service. This can cause an outage or service 208 degradation if the service makes a backward-incompatible 209 configuration change. Accordingly, zone owners SHOULD NOT publish 210 SvcParams for a TargetName that they do not control, and service 211 operators should take caution when making incompatible configuration 212 changes. 214 6. Security Considerations 216 This document specifies the use of TLSA as a property of each 217 connection attempt. In environments where DANE is optional, this 218 means that the fallback procedure might use DANE for some conection 219 attempts but not others. 221 This document only specifies the use of TLSA records when the SVCB 222 records were resolved securely. Use of TLSA records in conjunction 223 with insecurely resolved SVCB records is not safe in general, 224 although there may be some configurations where it is appropriate 225 (e.g. when only opportunistic security is available). 227 7. Examples 229 The following examples demonstrate Serving Binding interaction with 230 TLSA base domain selection. 232 All of the RRSets below are assumed fully-secure with all related 233 DNSSEC record types omitted for brevity. 235 7.1. HTTPS ServiceMode 237 Given service URI https://api.example.com and record: 239 api.example.com. HTTPS 1 . 241 The TLSA QNAME is _443._tcp.api.example.com. 243 7.2. HTTPS AliasMode 245 Given service URI https://api.example.com and records: 247 api.example.com. HTTPS 0 svc4.example.net. 248 svc4.example.net. HTTPS 0 xyz.example-cdn.com. 249 xyz.example-cdn.com. A 192.0.2.1 251 The TLSA QNAME is _443._tcp.xyz.example-cdn.com. 253 7.3. QUIC and CNAME 255 Given service URI https://api.example.com and records: 257 www.example.com. CNAME api.example.com. 258 api.example.com. HTTPS 1 svc4.example.net alpn=h2,h3 port=8443 259 svc4.example.net. CNAME xyz.example-cdn.com. 261 If the connection attempt is using HTTP/3, the transport label is set 262 to _quic\; otherwise _tcp is used. 264 The initial TLSA QNAME would be one of: 266 * _8443._quic.svc4.example.net 268 * _8443._tcp.svc4.example.net 270 If no TLSA record is found, the fallback TLSA QNAME would be one of: 272 * _8443._quic.xyz.example-cdn.com 274 * _8443._tcp.xyz.example-cdn.com 276 7.4. New scheme ServiceMode 278 Given service URI foo://api.example.com:8443 and record: 280 _8443._foo.api.example.com. SVCB 1 api.example.com. 282 The TLSA QNAME is _8443._$PROTO.api.example.com, where $PROTO is the 283 appropriate value for the client-selected transport as discussed in 284 Section 4 . 286 7.5. New scheme AliasMode 288 Given service URI foo://api.example.com:8443 and records: 290 _8443._foo.api.example.com. SVCB 0 svc4.example.net. 291 svc4.example.net. SVCB 1 . 292 svc4.example.net. A 192.0.2.1 294 The TLSA QNAME is _8443._$PROTO.svc4.example.net (with $PROTO as 295 above). This is the same if the ServiceMode record is absent. 297 7.6. New protocols 299 Given service URI foo://api.example.com:8443 and records: 301 _8443._foo.api.example.com. SVCB 0 svc4.example.net. 302 svc4.example.net. SVCB 3 . alpn=foo,bar port=8004 304 The TLSA QNAME is _8004._$PROTO1.svc4.example.net or 305 _8004._$PROTO2.svc4.example.net, where $PROTO1 and $PROTO2 are the 306 transport prefixes appropriate for "foo" and "bar" respectively. 307 (Note that SVCB requires each ALPN to unambiguously indicate a 308 transport.) 310 7.7. DNS ServiceMode 312 Given a DNS server dns.example.com and record: 314 _dns.dns.example.com. SVCB 1 dns.example.com. alpn=dot 316 The TLSA QNAME is _853._tcp.dns.example.com. The TLSA base name is 317 taken from the SVCB TargetName. The port and protocol are taken from 318 the "dot" ALPN value. 320 7.8. DNS AliasMode 322 Given a DNS server dns.example.com and records: 324 _dns.dns.example.com. SVCB 0 dns.my-dns-host.net. 325 dns.my-dns-host.net. SVCB 1 . alpn=dot 327 The TLSA QNAME is _853._tcp.ns1.my-dns-host.net. 329 8. IANA Considerations 331 IANA is instructed to add the following entry to the "Underscored and 332 Globally Scoped DNS Node Names" registry: 334 +=========+============+=================+ 335 | RR Type | _NODE NAME | Reference | 336 +=========+============+=================+ 337 | TLSA | _quic | (This document) | 338 +---------+------------+-----------------+ 340 Table 1 342 9. References 344 9.1. Normative References 346 [I-D.draft-ietf-tls-dtls13] 347 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 348 Datagram Transport Layer Security (DTLS) Protocol Version 349 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 350 dtls13-43, 30 April 2021, 351 . 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, 356 DOI 10.17487/RFC2119, March 1997, 357 . 359 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 360 Layer Security over Stream Control Transmission Protocol", 361 RFC 3436, DOI 10.17487/RFC3436, December 2002, 362 . 364 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 365 of Named Entities (DANE) Transport Layer Security (TLS) 366 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 367 2012, . 369 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 370 Authentication of Named Entities (DANE) Protocol: Updates 371 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 372 October 2015, . 374 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 375 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 376 May 2017, . 378 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 379 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 380 . 382 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 383 Multiplexed and Secure Transport", RFC 9000, 384 DOI 10.17487/RFC9000, May 2021, 385 . 387 [SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service binding 388 and parameter specification via the DNS (DNS SVCB and 389 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 390 dnsop-svcb-https-08, 12 October 2021, 391 . 394 9.2. Informative References 396 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 397 Opportunistic DNS-Based Authentication of Named Entities 398 (DANE) Transport Layer Security (TLS)", RFC 7672, 399 DOI 10.17487/RFC7672, October 2015, 400 . 402 [RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 403 Based Authentication of Named Entities (DANE) TLSA Records 404 with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 405 2015, . 407 Acknowledgments 409 TODO acknowledge. 411 Authors' Addresses 413 Benjamin M. Schwartz 414 Google LLC 416 Email: bemasc@google.com 418 Robert Evans 419 Google LLC 421 Email: evansr@google.com