idnits 2.17.1 draft-ietf-dane-ops-16.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 : ---------------------------------------------------------------------------- -- 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 draft header indicates that this document updates RFC6698, but the abstract doesn't seem to directly say this. It does mention RFC6698 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 9, 2015) is 3180 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DANE V. Dukhovni 3 Internet-Draft Unaffiliated 4 Updates: 6698 (if approved) W. Hardaker 5 Intended status: Standards Track Parsons 6 Expires: February 10, 2016 August 9, 2015 8 Updates to and Operational Guidance for the DANE Protocol 9 draft-ietf-dane-ops-16 11 Abstract 13 This document clarifies and updates the DNS-Based Authentication of 14 Named Entities (DANE) TLSA specification (RFC6698) based on 15 subsequent implementation experience. It also contains guidance for 16 implementers, operators and protocol developers who want to make use 17 of DANE records. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 10, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. DANE TLSA Record Overview . . . . . . . . . . . . . . . . . . 5 56 2.1. Example TLSA record . . . . . . . . . . . . . . . . . . . 6 57 3. DANE TLS Requirements . . . . . . . . . . . . . . . . . . . . 6 58 4. DANE Certificate Usage Selection Guidelines . . . . . . . . . 6 59 4.1. Opportunistic Security and PKIX usages . . . . . . . . . 7 60 4.2. Interaction with Certificate Transparency . . . . . . . . 8 61 4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE . . . . . 8 62 5. Certificate-Usage-Specific DANE Updates and Guidelines . . . 9 63 5.1. Certificate Usage DANE-EE(3) . . . . . . . . . . . . . . 9 64 5.2. Certificate Usage DANE-TA(2) . . . . . . . . . . . . . . 11 65 5.3. Certificate Usage PKIX-EE(1) . . . . . . . . . . . . . . 14 66 5.4. Certificate Usage PKIX-TA(0) . . . . . . . . . . . . . . 14 67 6. Service Provider and TLSA Publisher Synchronization . . . . . 15 68 7. TLSA Base Domain and CNAMEs . . . . . . . . . . . . . . . . . 18 69 8. TLSA Publisher Requirements . . . . . . . . . . . . . . . . . 19 70 8.1. Key rollover with fixed TLSA Parameters . . . . . . . . . 19 71 8.2. Switching to DANE-TA from DANE-EE . . . . . . . . . . . . 20 72 8.3. Switching to New TLSA Parameters . . . . . . . . . . . . 21 73 8.4. TLSA Publisher Requirements Summary . . . . . . . . . . . 22 74 9. Digest Algorithm Agility . . . . . . . . . . . . . . . . . . 22 75 10. General DANE Guidelines . . . . . . . . . . . . . . . . . . . 24 76 10.1. DANE DNS Record Size Guidelines . . . . . . . . . . . . 24 77 10.2. Certificate Name Check Conventions . . . . . . . . . . . 25 78 10.3. Design Considerations for Protocols Using DANE . . . . . 26 79 11. Note on DNSSEC Security . . . . . . . . . . . . . . . . . . . 26 80 12. Summary of Updates to RFC6698 . . . . . . . . . . . . . . . . 27 81 13. Operational Considerations . . . . . . . . . . . . . . . . . 28 82 14. Security Considerations . . . . . . . . . . . . . . . . . . . 29 83 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 84 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 85 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 86 17.1. Normative References . . . . . . . . . . . . . . . . . . 29 87 17.2. Informative References . . . . . . . . . . . . . . . . . 31 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 90 1. Introduction 92 The DNS-Based Authentication of Named Entities (DANE) specification 93 ([RFC6698]) introduces the DNS "TLSA" resource record type ("TLSA" is 94 not an acronym). TLSA records associate a certificate or a public 95 key of an end-entity or a trusted issuing authority with the 96 corresponding Transport Layer Security (TLS) [RFC5246] or Datagram 97 Transport Layer Security (DTLS) [RFC6347] transport endpoint. DANE 98 relies on the DNS Security Extensions (DNSSEC, [RFC4033]). DANE TLSA 99 records validated by DNSSEC can be used to augment or replace the use 100 of trusted public Certification Authorities (CAs). 102 The TLS and DTLS protocols provide secured TCP and UDP communication, 103 respectively, over IP. In the context of this document, channel 104 security is assumed to be provided by TLS or DTLS. By convention, 105 "TLS" will be used throughout this document and, unless otherwise 106 specified, the text applies equally well to DTLS over UDP. Used 107 without authentication, TLS provides protection only against 108 eavesdropping through its use of encryption. With authentication, 109 TLS also protects the transport against man-in-the-middle (MiTM) 110 attacks. 112 [RFC6698] defines three TLSA record fields, the first with 4 possible 113 values, the second with 2, and the third with 3. These yield 24 114 distinct combinations of TLSA record types. This document recommends 115 a smaller set of best-practice combinations of these fields to 116 simplify protocol design, implementation and deployment. 118 This document explains and recommends DANE-specific strategies to 119 simplify "virtual hosting", where a single Service Provider transport 120 endpoint simultaneously supports multiple hosted Customer Domains. 122 Other related documents that build on [RFC6698] are 123 [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]. 125 Section 12 summarizes the normative updates this document makes to 126 [RFC6698]. 128 1.1. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in 133 [RFC2119]. 135 The following terms are used throughout this document: 137 Web PKI: The Public Key Infrastructure (PKI) model employed by 138 browsers to authenticate web servers. This employs a set of 139 trusted public Certification Authorities (CAs) to vouch for the 140 authenticity of public keys associated with a particular party 141 (the subject). 143 Service Provider: A company or organization that offers to host a 144 service on behalf of the owner of a Customer Domain. The original 145 domain name associated with the service often remains under the 146 control of the customer. Connecting applications may be directed 147 to the Service Provider via a redirection resource record. 148 Example redirection records include MX, SRV, and CNAME. The 149 Service Provider frequently provides services for many customers 150 and needs to ensure that the TLS credentials presented to 151 connecting applications authenticate it as a valid server for the 152 requested domain. 154 Customer Domain: As described above, a TLS client may be interacting 155 with a service that is hosted by a third party. This document 156 refers to the domain name used to locate the service (prior to any 157 redirection) as the "Customer Domain". 159 TLSA Publisher: The entity responsible for publishing a TLSA record 160 within a DNS zone. This zone will be assumed DNSSEC-signed and 161 validatable to a trust anchor, unless otherwise specified. If the 162 Customer Domain is not outsourcing their DNS service, the TLSA 163 Publisher will be the customer themselves. Otherwise, the TLSA 164 Publisher may be the operator of the outsourced DNS service. 166 public key: The term "public key" is short-hand for the 167 subjectPublicKeyInfo component of a PKIX [RFC5280] certificate. 169 SNI: The "Server Name Indication" (SNI) TLS protocol extension 170 allows a TLS client to request a connection to a particular 171 service name of a TLS server ([RFC6066], section 3). Without this 172 TLS extension, a TLS server has no choice but to offer a 173 certificate with a default list of server names, making it 174 difficult to host multiple Customer Domains at the same IP- 175 address-based TLS service endpoint (i.e., provide "secure virtual 176 hosting"). 178 TLSA parameters: In [RFC6698] the TLSA record is defined to consist 179 of four fields. The first three of these are numeric parameters 180 that specify the meaning of the data in the fourth and final 181 field. This document refers to the first three fields as "TLSA 182 parameters", or sometimes just "parameters" when obvious from 183 context. 185 TLSA base domain: Per Section 3 of [RFC6698] TLSA records are stored 186 at a DNS domain name which is a combination of a port and protocol 187 prefix and a "base domain". In [RFC6698] the "base domain" is the 188 fully qualified domain name of the TLS server. This document 189 modifies the TLSA record lookup strategy to prefer the fully CNAME 190 expanded name of the TLS server, provided that expansion is 191 "secure" (DNSSEC validated) at each stage of the expansion, and 192 TLSA records are published for this fully expanded name. Thus the 193 "TLSA base domain" is either the fully CNAME expanded TLS server 194 name, or otherwise the initial fully qualified TLS server name, 195 whichever is used in combination with a port and protocol prefix 196 to obtain the TLSA RRset. 198 2. DANE TLSA Record Overview 200 DANE TLSA [RFC6698] specifies a protocol for publishing TLS server 201 certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035]. 202 DANE TLSA records consist of four fields: 204 The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies 4 205 values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3). There 206 is an additional private-use value: PrivCert(255), which, given 207 its private scope, shall not be considered further in this 208 document. All other values are reserved for use by future 209 specifications. 211 The Selector field: Section 2.1.2 of [RFC6698] specifies 2 values: 212 Cert(0), SPKI(1). There is an additional private-use value: 213 PrivSel(255). All other values are reserved for use by future 214 specifications. 216 The Matching Type field: Section 2.1.3 of [RFC6698] specifies 3 217 values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional 218 private-use value: PrivMatch(255). All other values are reserved 219 for use by future specifications. 221 The Certificate Association Data field: Section 2.1.4 of [RFC6698]. 222 This stores the full value or digest of the certificate or subject 223 public key as determined by the matching type and selector 224 respectively. 226 The record type is determined by the values of the first three 227 fields, which this document refers to as the "TLSA parameters", to 228 distinguish them from the fourth and last field. The numeric values 229 of these parameters were given symbolic names in [RFC7218]. 231 In the matching type field, of the two digest algorithms, for now 232 only SHA2-256(1) is mandatory to implement. Clients SHOULD implement 233 SHA2-512(2), but servers SHOULD NOT exclusively publish SHA2-512(2) 234 digests. The digest algorithm agility protocol defined in Section 9 235 SHOULD be used by clients to decide how to process TLSA RRsets that 236 employ multiple digest algorithms. Server operators MUST publish 237 TLSA RRsets that are compatible (see Section 8) with digest algorithm 238 agility (Section 9). 240 2.1. Example TLSA record 242 In the example TLSA record below: 244 _25._tcp.mail.example.com. IN TLSA 2 0 1 ( 245 E8B54E0B4BAA815B06D3462D65FBC7C0 246 CF556ECCF9F5303EBFBB77D022F834C0 ) 248 The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and 249 the matching type is SHA2-256(1). The last field is the Certificate 250 Association Data Field, which in this case contains the SHA2-256 251 digest of the server certificate. 253 3. DANE TLS Requirements 255 [RFC6698] does not discuss what versions of TLS are required when 256 using DANE records. This document specifies that TLS clients that 257 support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support 258 TLS 1.2 or later. 260 TLS clients using DANE MUST support the "Server Name Indication" 261 (SNI) extension of TLS ([RFC6066]). Servers MAY support SNI and 262 respond with a matching certificate chain, but MAY also ignore SNI 263 and respond with a default certificate chain. When a server supports 264 SNI but is not configured with a certificate chain that exactly 265 matches the client's SNI extension, the server SHOULD respond with 266 another certificate chain (a default or closest match). This is 267 because clients might support more than one server name, but can only 268 put a single name in the SNI extension. 270 4. DANE Certificate Usage Selection Guidelines 272 As mentioned in Section 2, the TLSA certificate usage field takes one 273 of four possible values. With PKIX-TA(0) and PKIX-EE(1), the 274 validation of peer certificate chains requires additional pre- 275 configured CA trust anchors that are mutually trusted by the 276 operators of the TLS server and client. With DANE-TA(2) and DANE- 277 EE(3), no pre-configured CA trust anchors are required and the 278 published DANE TLSA records are sufficient to verify the peer's 279 certificate chain. 281 Standards for application protocols that employ DANE TLSA can specify 282 more specific guidance than [RFC6698] or this document. Such 283 application-specific standards need to carefully consider which set 284 of DANE certificate usages to support. Simultaneous support for all 285 four usages is NOT RECOMMENDED for DANE clients. When all four 286 usages are supported, an attacker capable of compromising the 287 integrity of DNSSEC needs only to replace server's TLSA RRset with 288 one that lists suitable DANE-EE(3) or DANE-TA(2) records, effectively 289 bypassing any added verification via public CAs. In other words, 290 when all four usages are supported, PKIX-TA(2) and PKIX-EE(1) offer 291 only illusory incremental security over DANE-TA(2) and DANE-EE(3). 293 Designs in which clients support just the DANE-TA(2) and DANE-EE(3) 294 certificate usages are RECOMMENDED. With DANE-TA(2) and DANE-EE(3) 295 clients don't need to track a large changing list of X.509 trust- 296 anchors in order to successfully authenticate servers whose 297 certificates are issued by a brand new or not widely trusted CA. 299 The DNSSEC TLSA records for servers MAY include both sets of usages 300 if the server needs to support a mixture of clients, some supporting 301 one pair of usages and some the other. 303 4.1. Opportunistic Security and PKIX usages 305 When the client's protocol design is based on Opportunistic Security 306 (OS, [RFC7435]), and the use of authentication is based on the 307 presence of server TLSA records, it is especially important to avoid 308 the PKIX-EE(1) and PKIX-TA(0) certificate usages. 310 When authenticated TLS is used opportunistically, based on the 311 presence of DANE TLSA records, and no secure TLSA records are 312 present, unauthenticated TLS is used if possible, and otherwise 313 perhaps even cleartext. However, if usable secure TLSA records are 314 published then authentication MUST succeed. Also, outside the 315 browser space, there is no pre-ordained canon of trusted CAs, and in 316 any case there is no security advantage in using PKIX-TA(0) or PKIX- 317 EE(1) when the DANE-TA(2) and DANE-EE(3) usages are also supported 318 (as an attacker who can compromise DNS can replace the former with 319 the latter). 321 Authentication via the PKIX-TA(0) and PKIX-EE(1) certificate usages 322 is more brittle, the client and server need to happen to agree on a 323 mutually trusted CA, but with opportunistic security the client is 324 just trying to protect the communication channel at the request of 325 the server, and would otherwise be willing to use cleartext or 326 unauthenticated TLS. Use of fragile mechanisms (like public CA 327 authentication for some unspecified set of trusted CAs) is not 328 sufficiently reliable for an opportunistic security client to honor 329 the server's request for authentication. Opportunistic security 330 needs to be unintrusive and to require few, if any, work-arounds for 331 valid and yet mismatched peers. 333 With the PKIX-TA(0) and PKIX-EE(1) usages offering no more security, 334 but being more prone to failure, they are a poor fit for 335 opportunistic security and SHOULD NOT be used in that context. 337 4.2. Interaction with Certificate Transparency 339 Certificate Transparency (CT) [RFC6962] defines an experimental 340 approach that could be used to mitigate the risk of rogue or 341 compromised public CAs issuing unauthorized certificates. This 342 section clarifies the interaction of the experimental CT and DANE. 343 This section may need to be revised in light of any future standards 344 track version of CT. 346 When a server is authenticated via a DANE TLSA RR with TLSA 347 Certificate Usage DANE-EE(3), the domain owner has directly specified 348 the certificate associated with the given service without reference 349 to any public certification authority. Therefore, when a TLS client 350 authenticates the TLS server via a TLSA record with usage DANE-EE(3), 351 CT checks SHOULD NOT be performed. Publication of the server 352 certificate or public key (digest) in a TLSA record in a DNSSEC 353 signed zone by the domain owner assures the TLS client that the 354 certificate is not an unauthorized certificate issued by a rogue CA 355 without the domain owner's consent. 357 When a server is authenticated via a DANE TLSA record with TLSA usage 358 DANE-TA(2) and the server certificate does not chain to a known 359 public root CA, CT cannot apply (CT logs only accept chains that 360 start with a known public root). Since TLSA Certificate Usage DANE- 361 TA(2) is generally intended to support non-public trust anchors, TLS 362 clients SHOULD NOT perform CT checks with usage DANE-TA(2). 364 With certificate usages PKIX-TA(0) and PKIX-EE(1), CT applies just at 365 it would without DANE. TLSA records of this type only constrain 366 which CAs are acceptable in PKIX validation. All checks used in the 367 absence of DANE still apply when validating certificate chains with 368 DANE PKIX-TA(0) and PKIX-EE(1) constraints. 370 4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE 372 The choice of preferred certificate usages may need to change as an 373 application protocol evolves. When transitioning between PKIX-TA/ 374 PKIX-EE and DANE-TA/DANE-EE, clients begin to enable support for the 375 new certificate usage values. If the new preferred certificate 376 usages are PKIX-TA/EE this requires installing and managing the 377 appropriate set of CA trust anchors. During this time servers will 378 publish both types of TLSA records. At some later time when the vast 379 majority of servers have published the new preferred TLSA records, 380 clients can stop supporting the legacy certificate usages. 381 Similarly, servers can stop publishing legacy TLSA records once the 382 vast majority of clients support the new certificate usages. 384 5. Certificate-Usage-Specific DANE Updates and Guidelines 386 The four Certificate Usage values from the TLSA record, DANE-EE(3), 387 DANE-TA(2), PKIX-EE(1) and PKIX-TA(0), are discussed below. 389 5.1. Certificate Usage DANE-EE(3) 391 In this section the meaning of DANE-EE(3) is updated from [RFC6698] 392 to specify that peer identity matching and that validity period 393 enforcement is based solely on the TLSA RRset properties. This 394 document also extends [RFC6698] to cover the use of DANE 395 authentication of raw public keys [RFC7250] via TLSA records with 396 Certificate Usage DANE-EE(3) and selector SPKI(1). 398 Authentication via certificate usage DANE-EE(3) TLSA records involves 399 simply checking that the server's leaf certificate matches the TLSA 400 record. In particular, the binding of the server public key to its 401 name is based entirely on the TLSA record association. The server 402 MUST be considered authenticated even if none of the names in the 403 certificate match the client's reference identity for the server. 404 This simplifies the operation of servers that host multiple Customer 405 Domains, as a single certificate can be associated with multiple 406 domains, without having to match each of the corresponding reference 407 identifiers. 409 ; Multiple client domains hosted by example.net service provider: 410 ; 411 www.example.com. IN CNAME ex-com.example.net. 412 www.example.org. IN CNAME ex-org.example.net. 413 ; 414 ; In the provider's DNS zone, a single certificate and TLSA 415 ; record supports multiple client domains, greatly simplifying 416 ; "virtual hosting". 417 ; 418 ex-com.example.net. IN A 192.0.2.1 419 ex-org.example.net. IN A 192.0.2.1 420 _443._tcp.ex-com.example.net. IN CNAME tlsa._dane.example.net. 421 _443._tcp.ex-org.example.net. IN CNAME tlsa._dane.example.net. 422 tlsa._dane.example.net. IN TLSA 3 1 1 e3b0c44298fc1c14... 424 Also with DANE-EE(3), the expiration date of the server certificate 425 MUST be ignored. The validity period of the TLSA record key binding 426 is determined by the validity period of the TLSA record DNSSEC 427 signatures. Validity is reaffirmed on an ongoing basis by continuing 428 to publish the TLSA record and sign the containing zone, rather than 429 via dates set in stone in certificate. The expiration becomes a 430 reminder to the administrator that it is likely time to rotate the 431 key, but missing the date no longer causes an outage. When keys are 432 rotated (for whatever reason) it is important to follow the 433 procedures outlined in Section 8. 435 If a server uses just DANE-EE(3) TLSA records, and all its clients 436 are DANE clients, the server need not employ SNI (i.e., it may ignore 437 the client's SNI message) even when the server is known via multiple 438 domain names that would otherwise require separate certificates. It 439 is instead sufficient for the TLSA RRsets for all the domain names in 440 question to match the server's default certificate. For application 441 protocols where the server name is obtained indirectly via SRV, MX or 442 similar records, it is simplest to publish a single hostname as the 443 target server name for all the hosted domains. 445 In organizations where it is practical to make coordinated changes in 446 DNS TLSA records before server key rotation, it is generally best to 447 publish end-entity DANE-EE(3) certificate associations in preference 448 to other choices of certificate usage. DANE-EE(3) TLSA records 449 support multiple server names without SNI, don't suddenly stop 450 working when leaf or intermediate certificates expire, and don't fail 451 when a server operator neglects to include all the required issuer 452 certificates in the server certificate chain. 454 More specifically, it is RECOMMENDED that at most sites TLSA records 455 published for DANE servers be "DANE-EE(3) SPKI(1) SHA2-256(1)" 456 records. Selector SPKI(1) is chosen because it is compatible with 457 raw public keys ([RFC7250]) and the resulting TLSA record need not 458 change across certificate renewals with the same key. Matching type 459 SHA2-256(1) is chosen because all DANE implementations are required 460 to support SHA2-256. This TLSA record type easily supports hosting 461 arrangements with a single certificate matching all hosted domains. 462 It is also the easiest to implement correctly in the client. 464 Clients that support raw public keys can use DANE TLSA records with 465 certificate usage DANE-EE(3) and selector SPKI(1) to authenticate 466 servers that negotiate the use of raw public keys. Provided the 467 server adheres to the requirements of Section 8, the fact that raw 468 public keys are not compatible with any other TLSA record types will 469 not get in the way of successful authentication. Clients that employ 470 DANE to authenticate the peer server SHOULD NOT negotiate the use of 471 raw public keys unless the server's TLSA RRset includes DANE-EE(3) 472 SPKI(1) TLSA records. 474 While it is, in principle, also possible to authenticate raw public 475 keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the 476 public key from the certificate in DNS, extracting just the the 477 public key from a "3 0 0" TLSA record requires extra logic on clients 478 that not all implementations are expected to provide. Servers that 479 wish to support [RFC7250] raw public keys need to publish TLSA 480 records with a certificate usage of DANE-EE(3) and a selector of 481 SPKI(1). 483 While DANE-EE(3) TLSA records are expected to be by far the most 484 prevalent, as explained in Section 5.2 DANE-TA(2) records are a valid 485 alternative for sites with many DANE services. Note however, that 486 virtual hosting is more complex with DANE-TA(2). Also with DANE- 487 TA(2) server operators MUST ensure that the server is configured with 488 a sufficiently complete certificate chain and need to remember to 489 replace certificates prior to their expiration dates. 491 5.2. Certificate Usage DANE-TA(2) 493 This section updates [RFC6698] by specifying a new operational 494 requirement for servers publishing TLSA records with a usage of DANE- 495 TA(2): such servers MUST include the trust-anchor certificate in 496 their TLS server certificate message unless all such TLSA records are 497 "2 0 0" records that publish the server certificate in full. 499 Some domains may prefer to avoid the operational complexity of 500 publishing unique TLSA RRs for each TLS service. If the domain 501 employs a common issuing Certification Authority to create 502 certificates for multiple TLS services, it may be simpler to publish 503 the issuing authority as a trust anchor (TA) for the certificate 504 chains of all relevant services. The TLSA query domain (TLSA base 505 domain with port and protocol prefix labels) for each service issued 506 by the same TA may then be set to a CNAME alias that points to a 507 common TLSA RRset that matches the TA. For example: 509 ; Two servers, each with its own certificate, that share 510 ; a common issuer (trust-anchor). 511 ; 512 www1.example.com. IN A 192.0.2.1 513 www2.example.com. IN A 192.0.2.2 514 _443._tcp.www1.example.com. IN CNAME tlsa._dane.example.com. 515 _443._tcp.www2.example.com. IN CNAME tlsa._dane.example.com. 516 tlsa._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14... 518 The above configuration simplifies server key rotation, because while 519 the servers continue to receive new certificates from a CA matched by 520 the shared (target of the CNAMEs) TLSA record, servers certificates 521 can be updated without making any DNS changes. As the list of active 522 issuing CAs changes, the shared TLSA record will be updated (much 523 less frequently) by the administrators who manage the CAs. Those 524 administrators still need to perform TLSA record updates with care as 525 described in Section 8. 527 With usage DANE-TA(2) the server certificates will need to have names 528 that match one of the client's reference identifiers (see [RFC6125]). 529 When hosting multiple unrelated client domains (that can't all appear 530 in a single certificate), such a server SHOULD employ SNI to select 531 the appropriate certificate to present to the client. 533 5.2.1. Recommended record combinations 535 TLSA records with matching type Full(0) are NOT RECOMMENDED. While 536 these potentially obviate the need to transmit the TA certificate in 537 the TLS server certificate message, client implementations may not be 538 able to augment the server certificate chain with the data obtained 539 from DNS, especially when the TLSA record supplies a bare key 540 (selector SPKI(1)). Since the server will need to transmit the TA 541 certificate in any case, server operators SHOULD publish TLSA records 542 with a matching type other than Full(0) and avoid potential DNS 543 interoperability issues with large TLSA records containing full 544 certificates or keys (see Section 10.1.1). 546 TLSA Publishers employing DANE-TA(2) records SHOULD publish records 547 with a selector of Cert(0). Such TLSA records are associated with 548 the whole trust anchor certificate, not just with the trust anchor 549 public key. In particular, when authenticating the peer certificate 550 chain via such a TLSA record, the client SHOULD apply any relevant 551 constraints from the trust anchor certificate, such as, for example, 552 path length constraints. 554 While a selector of SPKI(1) may also be employed, the resulting TLSA 555 record will not specify the full trust anchor certificate content, 556 and elements of the trust anchor certificate other than the public 557 key become mutable. This may, for example, enable a subsidiary CA to 558 issue a chain that violates the trust anchor's path length or name 559 constraints. 561 5.2.2. Trust anchor digests and server certificate chain 563 With DANE-TA(2), a complication arises when the TA certificate is 564 omitted from the server's certificate chain, perhaps on the basis of 565 Section 7.4.2 of [RFC5246]: 567 The sender's certificate MUST come first in the list. 568 Each following certificate MUST directly certify the one 569 preceding it. Because certificate validation requires 570 that root keys be distributed independently, the 571 self-signed certificate that specifies the root 572 certification authority MAY be omitted from the chain, 573 under the assumption that the remote end must already 574 possess it in order to validate it in any case. 576 With TLSA Certificate Usage DANE-TA(2), there is no expectation that 577 the client is pre-configured with the trust anchor certificate. In 578 fact, client implementations are free to ignore all locally 579 configured trust anchors when processing usage DANE-TA(2) TLSA 580 records and may rely exclusively on the certificates provided in the 581 server's certificate chain. But, with a digest in the TLSA record, 582 the TLSA record contains neither the full trust anchor certificate 583 nor the full public key. If the TLS server's certificate chain does 584 not contain the trust anchor certificate, DANE clients will be unable 585 to authenticate the server. 587 TLSA Publishers that publish TLSA Certificate Usage DANE-TA(2) 588 associations with a selector of SPKI(1) or using a digest-based 589 matching type (not Full(0)) MUST ensure that the corresponding server 590 is configured to also include the trust anchor certificate in its TLS 591 handshake certificate chain, even if that certificate is a self- 592 signed root CA and would have been optional in the context of the 593 existing public CA PKI. 595 Only when the server TLSA record includes a "DANE-TA(2) Cert(0) 596 Full(0)" TLSA record containing a full trust-anchor certificate, is 597 the trust-anchor certificate optional in the server's TLS certificate 598 message. Only in this case, the client MUST also be able to verify 599 the server's certificate chain via a trust-anchor provided via DNS 600 rather than via the TLS handshake server certificate message. 602 5.2.3. Trust anchor public keys 604 TLSA records with TLSA Certificate Usage DANE-TA(2), selector SPKI(1) 605 and a matching type of Full(0) publish the full public key of a trust 606 anchor via DNS. In section 6.1.1 of [RFC5280] the definition of a 607 trust anchor consists of the following four parts: 609 1. the trusted issuer name, 611 2. the trusted public key algorithm, 613 3. the trusted public key, and 615 4. optionally, the trusted public key parameters associated with the 616 public key. 618 Items 2-4 are precisely the contents of the subjectPublicKeyInfo 619 published in the TLSA record. The issuer name is not included in the 620 subjectPublicKeyInfo. 622 With TLSA Certificate Usage DANE-TA(2), the client may not have the 623 associated trust anchor certificate, and cannot generally verify 624 whether a particular certificate chain is "issued by" the trust 625 anchor described in the TLSA record. 627 When the server certificate chain includes a CA certificate whose 628 public key matches the TLSA record, the client can match that CA as 629 the intended issuer. Otherwise, the client can only check that the 630 topmost certificate in the server's chain is "signed by" the trust 631 anchor's public key in the TLSA record. Such a check may be 632 difficult to implement, and cannot be expected to be supported by all 633 clients. 635 Thus, servers cannot rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA 636 records to be sufficient to authenticate chains issued by the 637 associated public key in the absence of a corresponding certificate 638 in the server's TLS certificate message. Servers employing "2 1 0" 639 TLSA records, MUST include the corresponding trust-anchor certificate 640 in their certificate chain. 642 If none of the server's certificate chain elements match a public key 643 specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1) 644 Full(0)" TLSA record is available, it is RECOMMENDED that clients 645 check whether the topmost certificate in the chain is signed by the 646 provided public key and has not expired, and in that case consider 647 the server authenticated, provided the rest of the chain passes 648 validation including leaf certificate name checks. 650 5.3. Certificate Usage PKIX-EE(1) 652 This Certificate Usage is similar to DANE-EE(3), but in addition PKIX 653 verification is required. Therefore, name checks, certificate 654 expiration, certificate transparency, etc., apply as they would 655 without DANE. 657 5.4. Certificate Usage PKIX-TA(0) 659 This section updates [RFC6698] by specifying new client 660 implementation requirements. Clients that trust intermediate 661 certificates MUST be prepared to construct longer PKIX chains than 662 would be required for PKIX alone. 664 TLSA Certificate Usage PKIX-TA(0) allows a domain to publish 665 constraints on the set of PKIX certification authorities trusted to 666 issue certificates for its TLS servers. A PKIX-TA(0) TLSA record 667 matches PKIX-verified trust chains which contain an issuer 668 certificate (root or intermediate) that matches its certificate 669 association data field (typically a certificate or digest). 671 PKIX-TA(0) requires more complex coordination (than with DANE-TA(2) 672 or DANE-EE(3)) between the Customer Domain and the Service Provider 673 in hosting arrangements. Thus, this certificate usage is NOT 674 RECOMMENDED when the Service Provider is not also the TLSA Publisher 675 (at the TLSA base domain obtained via CNAMEs, SRV or MX records). 677 TLSA Publishers who publish TLSA records for a particular public root 678 CA, will expect that clients will only accept chains anchored at that 679 root. It is possible, however, that the client's trusted certificate 680 store includes some intermediate CAs, either with or without the 681 corresponding root CA. When a client constructs a trust chain 682 leading from a trusted intermediate CA to the server leaf 683 certificate, such a "truncated" chain might not contain the trusted 684 root published in the server's TLSA record. 686 If the omitted root is also trusted, the client may erroneously 687 reject the server chain if it fails to determine that the shorter 688 chain it constructed extends to a longer trusted chain that matches 689 the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record, 690 while no matching certificate is found, a client MUST continue 691 extending the chain even after any locally trusted certificate is 692 found. If no TLSA records have matched any of the elements of the 693 chain, and the trusted certificate found is not self-issued, the 694 client MUST attempt to build a longer chain in case a certificate 695 closer to the root matches the server's TLSA record. 697 6. Service Provider and TLSA Publisher Synchronization 699 Whenever possible, the TLSA Publisher and the Service Provider should 700 be the same entity. Otherwise, they need to coordinate changes to 701 ensure that TLSA records published by the TLSA Publisher don't fall 702 out of sync with the server certificate used by the Service Provider. 703 Such coordination is difficult and service outages will result when 704 coordination fails. 706 Publishing the TLSA record in the Service Provider's zone avoids the 707 complexity of bilateral coordination of server certificate 708 configuration and TLSA record management. Even when the TLSA RRset 709 has to be published in the Customer Domain's DNS zone (perhaps the 710 client application does not "chase" CNAMEs to the TLSA base domain), 711 it is possible to employ CNAME records to delegate the content of the 712 TLSA RRset to a domain operated by the Service Provider. 714 Only Certificate Usages DANE-EE(3) and DANE-TA(2) work well with TLSA 715 CNAMEs across organizational boundaries. With PKIX-TA(0) or PKIX- 716 EE(1) the Service Provider would need to obtain certificates in the 717 name of Customer Domain from a suitable public CA (securely 718 impersonate the customer), or the customer would need to provision 719 the relevant private keys and certificates at the Service Provider's 720 systems. 722 Certificate Usage DANE-EE(3): In this case the Service Provider can 723 publish a single TLSA RRset that matches the server certificate or 724 public key digest. The same RRset works for all Customer Domains 725 because name checks do not apply with DANE-EE(3) TLSA records (see 726 Section 5.1). A Customer Domain can create a CNAME record 727 pointing to the TLSA RRset published by the Service Provider. 729 Certificate Usage DANE-TA(2): When the Service Provider operates a 730 private certification authority, the Service Provider is free to 731 issue a certificate bearing any customer's domain name. Without 732 DANE, such a certificate would not pass trust verification, but 733 with DANE, the customer's TLSA RRset that is aliased to the 734 provider's TLSA RRset can delegate authority to the provider's CA 735 for the corresponding service. The Service Provider can generate 736 appropriate certificates for each customer and use the SNI 737 information provided by clients to select the right certificate 738 chain to present to each client. 740 Below are example DNS records (assumed "secure" and shown without the 741 associated DNSSEC information, such as record signatures) that 742 illustrate both of of the above models in the case of an HTTPS 743 service whose clients all support DANE TLS. These examples work even 744 with clients that don't "chase" CNAMEs when constructing the TLSA 745 base domain (see Section 7 below). 747 ; The hosted web service is redirected via a CNAME alias. 748 ; The associated TLSA RRset is also redirected via a CNAME alias. 749 ; 750 ; A single certificate at the provider works for all Customer 751 ; Domains due to the use of the DANE-EE(3) Certificate Usage. 752 ; 753 www1.example.com. IN CNAME w1.example.net. 754 _443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net. 755 _443._tcp.w1.example.net. IN TLSA 3 1 1 ( 756 8A9A70596E869BED72C69D97A8895DFA 757 D86F300A343FECEFF19E89C27C896BC9 ) 759 ; 760 ; A CA at the provider can also issue certificates for each Customer 761 ; Domain, and use the DANE-TA(2) Certificate Usage type to 762 ; indicate a trust anchor. 763 ; 764 www2.example.com. IN CNAME w2.example.net. 765 _443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net. 766 _443._tcp.w2.example.net. IN TLSA 2 0 1 ( 767 C164B2C3F36D068D42A6138E446152F5 768 68615F28C69BD96A73E354CAC88ED00C ) 770 With protocols that support explicit transport redirection via DNS MX 771 records, SRV records, or other similar records, the TLSA base domain 772 is based on the redirected transport end-point, rather than the 773 origin domain. With SMTP, for example, when an email service is 774 hosted by a Service Provider, the Customer Domain's MX hostnames will 775 point at the Service Provider's SMTP hosts. When the Customer 776 Domain's DNS zone is signed, the MX hostnames can be securely used as 777 the base domains for TLSA records that are published and managed by 778 the Service Provider. For example (without the required DNSSEC 779 information, such as record signatures): 781 ; Hosted SMTP service 782 ; 783 example.com. IN MX 0 mx1.example.net. 784 example.com. IN MX 0 mx2.example.net. 785 _25._tcp.mx1.example.net. IN TLSA 3 1 1 ( 786 8A9A70596E869BED72C69D97A8895DFA 787 D86F300A343FECEFF19E89C27C896BC9 ) 788 _25._tcp.mx2.example.net. IN TLSA 3 1 1 ( 789 C164B2C3F36D068D42A6138E446152F5 790 68615F28C69BD96A73E354CAC88ED00C ) 792 If redirection to the Service Provider's domain (via MX or SRV 793 records or any similar mechanism) is not possible, and aliasing of 794 the TLSA record is not an option, then more complex coordination 795 between the Customer Domain and Service Provider will be required. 796 Either the Customer Domain periodically provides private keys and a 797 corresponding certificate chain to the Provider (after making 798 appropriate changes in its TLSA records), or the Service Provider 799 periodically generates the keys and certificates and needs to wait 800 for matching TLSA records to be published by its Customer Domains 801 before deploying newly generated keys and certificate chains. 802 Section 7 below describes an approach that employs CNAME "chasing" to 803 avoid the difficulties of coordinating key management across 804 organization boundaries. 806 For further information about combining DANE and SRV, please see 807 [I-D.ietf-dane-srv]. 809 7. TLSA Base Domain and CNAMEs 811 When the application protocol does not support service location 812 indirection via MX, SRV or similar DNS records, the service may be 813 redirected via a CNAME. A CNAME is a more blunt instrument for this 814 purpose, since unlike an MX or SRV record, it remaps the entire 815 origin domain to the target domain for all protocols. 817 The complexity of coordinating key management is largely eliminated 818 when DANE TLSA records are found in the Service Provider's domain, as 819 discussed in Section 6. Therefore, DANE TLS clients connecting to a 820 server whose domain name is a CNAME alias SHOULD follow the CNAME 821 hop-by-hop to its ultimate target host (noting at each step whether 822 the CNAME is DNSSEC-validated). If at each stage of CNAME expansion 823 the DNSSEC validation status is "secure", the final target name 824 SHOULD be the preferred base domain for TLSA lookups. 826 Implementations failing to find a TLSA record using a base name of 827 the final target of a CNAME expansion SHOULD issue a TLSA query using 828 the original destination name. That is, the preferred TLSA base 829 domain SHOULD be derived from the fully expanded name, and failing 830 that SHOULD be the initial domain name. 832 When the TLSA base domain is the result of "secure" CNAME expansion, 833 the resulting domain name MUST be used as the HostName in the 834 client's SNI extension, and MUST be the primary reference identifier 835 for peer certificate matching with certificate usages other than 836 DANE-EE(3). 838 Protocol-specific TLSA specifications may provide additional guidance 839 or restrictions when following CNAME expansions. 841 Though CNAMEs are illegal on the right hand side of most indirection 842 records, such as MX and SRV records, they are supported by some 843 implementations. For example, if the MX or SRV host is a CNAME 844 alias, some implementations may "chase" the CNAME. If they do, they 845 SHOULD use the target hostname as the preferred TLSA base domain as 846 described above (and if the TLSA records are found there, use the 847 CNAME expanded domain also in SNI and certificate name checks). 849 8. TLSA Publisher Requirements 851 This section updates [RFC6698] by specifying that the TLSA Publisher 852 MUST ensure that each combination of Certificate Usage, selector and 853 matching type in the server's TLSA RRset includes at least one record 854 that matches the server's current certificate chain. TLSA records 855 that match recently retired or yet to be deployed certificate chains 856 will be present during key rollover. Such past or future records 857 MUST NOT at any time be the only records published for any given 858 combination of usage, selector and matching type. The TLSA record 859 update process described below ensures that this requirement is met. 861 While a server is to be considered authenticated when its certificate 862 chain is matched by any of the published TLSA records, not all 863 clients support all combinations of TLSA record parameters. Some 864 clients may not support some digest algorithms, others may either not 865 support, or may exclusively support, the PKIX Certificate Usages. 866 Some clients may prefer to negotiate [RFC7250] raw public keys, which 867 are only compatible with TLSA records whose Certificate Usage is 868 DANE-EE(3) with selector SPKI(1). The only other TLSA record type 869 that is potentially compatible with raw public keys is DANE-EE(3) 870 Cert(0) Full(0), but support for raw public keys with that TLSA 871 record type is not expected to be broadly implemented. 873 A consequence of the above uncertainty as to which TLSA parameters 874 are supported by any given client is that servers need to ensure that 875 each and every parameter combination that appears in the TLSA RRset 876 is, on its own, sufficient to match the server's current certificate 877 chain. In particular, when deploying new keys or new parameter 878 combinations some care is required to not generate parameter 879 combinations that only match past or future certificate chains (or 880 raw public keys). The rest of this section explains how to update 881 the TLSA RRset in a manner that ensures the above requirement is met. 883 8.1. Key rollover with fixed TLSA Parameters 885 The simplest case is key rollover while retaining the same set of 886 published parameter combinations. In this case, TLSA records 887 matching the existing server certificate chain (or raw public keys) 888 are first augmented with corresponding records matching the future 889 keys, at least two TTLs or longer before the the new chain is 890 deployed. This allows the obsolete RRset to age out of client caches 891 before the new chain is used in TLS handshakes. Once sufficient time 892 has elapsed and all clients performing DNS lookups are retrieving the 893 updated TLSA records, the server administrator may deploy the new 894 certificate chain, verify that it works, and then remove any obsolete 895 records matching the no longer active chain: 897 ; Initial TLSA RRset 898 ; 899 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 901 ; Transitional TLSA RRset published at least 2 TTLs before 902 ; the actual key change 903 ; 904 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 905 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 907 ; Final TLSA RRset after the key change 908 ; 909 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 911 The next case to consider is adding or switching to a new combination 912 of TLSA parameters. In this case publish the new parameter 913 combinations for the server's existing certificate chain first, and 914 only then deploy new keys if desired: 916 ; Initial TLSA RRset 917 ; 918 _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46... 920 ; New TLSA RRset, same key re-published as DANE-EE(3) 921 ; 922 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 924 8.2. Switching to DANE-TA from DANE-EE 926 This section explains how to migrate to a new certificate chain and 927 TLSA record with usage DANE-TA(2) from a self-signed server 928 certificate and a DANE-EE(3) SPKI(1) SHA2-256(1) TLSA record. This 929 example assumes that a new private key is generated in conjunction 930 with transitioning to a new certificate issued by the desired trust- 931 anchor. 933 The original "3 1 1" TLSA record supports [RFC7250] raw public keys, 934 and clients may choose to negotiate their use. Use of raw public 935 keys rules out the possibility of certificate chain verification. 936 Therefore, the transitional TLSA record for the planned DANE-TA(2) 937 certificate chain is a "3 1 1" record that works even when raw public 938 keys are used. The TLSA RRset is updated to use DANE-TA(2) only 939 after the new chain is deployed and the "3 1 1" record matching the 940 original key is dropped. 942 This process follows the requirement that each combination of 943 parameters present in the RRset is always sufficient to validate the 944 server. It avoids publishing a transitional TLSA RRset in which "3 1 945 1" matches only the current key and "2 0 1" matches only the future 946 certificate chain, because these might not work reliably during the 947 initial deployment of the new keys. 949 ; Initial TLSA RRset 950 ; 951 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 953 ; Transitional TLSA RRset, published at least 2 TTLs before the 954 ; actual key change. The new keys are issued by a DANE-TA(2) CA, 955 ; but are initially specified via a DANE-EE(3) association. 956 ; 957 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 958 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 960 ; The final TLSA RRset after the key change. Now that the old 961 ; self-signed EE key is out of the picture, publish the issuing 962 ; TA of the new chain. 963 ; 964 _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d... 966 8.3. Switching to New TLSA Parameters 968 When employing a new digest algorithm in the TLSA RRset, for 969 compatibility with digest agility specified in Section 9 below, 970 administrators SHOULD publish the new digest algorithm with each 971 combination of Certificate Usage and selector for each associated key 972 or chain used with any other digest algorithm. When removing an 973 algorithm, remove it entirely. Each digest algorithm employed SHOULD 974 match the same set of chains (or raw public keys). 976 ; Initial TLSA RRset with DANE-EE SHA2-256 associations for two keys. 977 ; 978 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 979 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 981 ; New TLSA RRset also with SHA2-512 associations for each key 982 ; 983 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 984 _443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc... 985 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 986 _443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714... 988 8.4. TLSA Publisher Requirements Summary 990 In summary, server operators updating TLSA records should make one 991 change at a time. The individual safe changes are: 993 o Pre-publish new certificate associations that employ the same TLSA 994 parameters (usage, selector and matching type) as existing TLSA 995 records, but match certificate chains that will be deployed in the 996 near future. 998 o Wait for stale TLSA RRsets to expire from DNS caches before 999 configuring servers to use the new certificate chain. 1001 o Remove TLSA records matching no longer deployed certificate 1002 chains. 1004 o Publish TLSA RRsets in which all parameter combinations 1005 (certificate usage, selector and matching type) present in the 1006 RRset match the same set of current and planned certificate 1007 chains. 1009 The above steps are intended to ensure that at all times and for each 1010 combination of usage, selector and matching type at least one TLSA 1011 record corresponds to the server's current certificate chain. Each 1012 combination of Certificate Usage, selector and matching type in a 1013 server's TLSA RRset SHOULD NOT at any time (including unexpired 1014 RRsets in client caches) match only some combination of future or 1015 past certificate chains. As a result, no matter what combinations of 1016 usage, selector and matching type may be supported by a given client, 1017 they will be sufficient to authenticate the server. 1019 9. Digest Algorithm Agility 1021 While [RFC6698] specifies multiple digest algorithms, it does not 1022 specify a protocol by which the client and TLSA record publisher can 1023 agree on the strongest shared algorithm. Such a protocol would allow 1024 the client and server to avoid exposure to deprecated weaker 1025 algorithms that are published for compatibility with less capable 1026 clients, but which SHOULD be avoided when possible. Such a protocol 1027 is specified below. 1029 This section defines a protocol for avoiding deprecated digest 1030 algorithms when these are published in a peer's TLSA RRset alongside 1031 stronger digest algorithms. Note that this protocol never avoids RRs 1032 with DANE matching type Full(0), as these do not employ a digest 1033 algorithm that might some day be weakened by cryptanalysis. 1035 Client implementations SHOULD implement a default order of digest 1036 algorithms by strength. This order SHOULD be configurable by the 1037 administrator or user of the client software. If possible, a 1038 configurable mapping from numeric DANE TLSA matching types to 1039 underlying digest algorithms provided by the cryptographic library 1040 SHOULD be implemented to allow new matching types to be used with 1041 software that predates their introduction. Configurable ordering of 1042 digest algorithms SHOULD be extensible to any new digest algorithms. 1044 To make digest algorithm agility possible, all published DANE TLSA 1045 RRsets MUST conform to the requirements of Section 8. Clients SHOULD 1046 use digest algorithm agility when processing the peer's DANE TLSA 1047 records. Algorithm agility is to be applied after first discarding 1048 any unusable or malformed records (unsupported digest algorithm, or 1049 incorrect digest length). For each usage and selector, the client 1050 SHOULD process only any usable records with a matching type of 1051 Full(0) and the usable records whose digest algorithm is considered 1052 by the client to be the strongest among usable records with the given 1053 usage and selector. 1055 Example: a client implements digest agility and prefers SHA2-512(2) 1056 over SHA2-256(1), while the server publishes an RRset that employs 1057 both digest algorithms as well as a Full(0) record. 1059 _25._tcp.mail.example.com. IN TLSA 3 1 1 ( 1060 3FE246A848798236DD2AB78D39F0651D 1061 6B6E7CA8E2984012EB0A2E1AC8A87B72 ) 1062 _25._tcp.mail.example.com. IN TLSA 3 1 2 ( 1063 D4F5AF015B46C5057B841C7E7BAB759C 1064 BF029526D29520C5BE6A32C67475439E 1065 54AB3A945D80C743347C9BD4DADC9D8D 1066 57FAB78EAA835362F3CA07CCC19A3214 ) 1067 _25._tcp.mail.example.com. IN TLSA 3 1 0 ( 1068 3059301306072A8648CE3D020106082A 1069 8648CE3D0301070342000471CB1F504F 1070 9E4B33971376C005445DACD33CD79A28 1071 81C3DED1981F18E7AAA76609DD0E4EF2 1072 8265C82703030AD60C5DBA6FB8A9397A 1073 C0FCF06D424C885D484887 ) 1075 In this case the client SHOULD accept a server public key that 1076 matches either the "3 1 0" record or the "3 1 2" record, but SHOULD 1077 NOT accept keys that match only the weaker "3 1 1" record. 1079 10. General DANE Guidelines 1081 These guidelines provide guidance for using or designing protocols 1082 for DANE. 1084 10.1. DANE DNS Record Size Guidelines 1086 Selecting a combination of TLSA parameters to use requires careful 1087 thought. One important consideration to take into account is the 1088 size of the resulting TLSA record after its parameters are selected. 1090 10.1.1. UDP and TCP Considerations 1092 Deployments SHOULD avoid TLSA record sizes that cause UDP 1093 fragmentation. 1095 Although DNS over TCP would provide the ability to more easily 1096 transfer larger DNS records between clients and servers, it is not 1097 universally deployed and is still prohibited by some firewalls. 1098 Clients that request DNS records via UDP typically only use TCP upon 1099 receipt of a truncated response in the DNS response message sent over 1100 UDP. Setting the TC bit alone will be insufficient if the response 1101 containing the TC bit is itself fragmented. 1103 10.1.2. Packet Size Considerations for TLSA Parameters 1105 Server operators SHOULD NOT publish TLSA records using both a TLSA 1106 Selector of Cert(0) and a TLSA Matching Type of Full(0), as even a 1107 single certificate is generally too large to be reliably delivered 1108 via DNS over UDP. Furthermore, two TLSA records containing full 1109 certificates will need to be published simultaneously during a 1110 certificate rollover, as discussed in Section 8.1. 1112 While TLSA records using a TLSA Selector of SPKI(1) and a TLSA 1113 Matching Type of Full(0) (which publish the bare public keys without 1114 the overhead of a containing X.509 certificate) are generally more 1115 compact, these are also best avoided when significantly larger than 1116 their digests. Rather, servers SHOULD publish digest-based TLSA 1117 Matching Types in their TLSA records. In which case, the complete 1118 corresponding certificate MUST be transmitted to the client in-band 1119 during the TLS handshake. The certificate (or raw public key) can be 1120 easily verified using the digest value. 1122 In summary, the use of a TLSA Matching Type of Full(0) is NOT 1123 RECOMMENDED and a digest-based matching type, such as SHA2-256(1), 1124 SHOULD be used instead. 1126 10.2. Certificate Name Check Conventions 1128 Certificates presented by a TLS server will generally contain a 1129 subjectAltName (SAN) extension or a Common Name (CN) element within 1130 the subject distinguished name (DN). The TLS server's DNS domain 1131 name is normally published within these elements, ideally within the 1132 subjectAltName extension. (The use of the CN field for this purpose 1133 is deprecated.) 1135 When a server hosts multiple domains at the same transport endpoint, 1136 the server's ability to respond with the right certificate chain is 1137 predicated on correct SNI information from the client. DANE clients 1138 MUST send the SNI extension with a HostName value of the base domain 1139 of the TLSA RRset. 1141 Except with TLSA Certificate Usage DANE-EE(3), where name checks are 1142 not applicable (see Section 5.1), DANE clients MUST verify that the 1143 client has reached the correct server by checking that the server 1144 name is listed in the server certificate's SAN or CN (when still 1145 supported). The primary server name used for this comparison MUST be 1146 the TLSA base domain, however additional acceptable names may be 1147 specified by protocol-specific DANE standards. For example, with 1148 SMTP both the destination domain name and the MX host name are 1149 acceptable names to be found in the server certificate (see 1150 [I-D.ietf-dane-smtp-with-dane]). 1152 It is the responsibility of the service operator, in coordination 1153 with the TLSA Publisher, to ensure that at least one of the TLSA 1154 records published for the service will match the server's certificate 1155 chain (either the default chain or the certificate that was selected 1156 based on the SNI information provided by the client). 1158 Given the DNSSEC validated DNS records below: 1160 example.com. IN MX 0 mail.example.com. 1161 mail.example.com. IN A 192.0.2.1 1162 _25._tcp.mail.example.com. IN TLSA 2 0 1 ( 1163 E8B54E0B4BAA815B06D3462D65FBC7C0 1164 CF556ECCF9F5303EBFBB77D022F834C0 ) 1166 The TLSA base domain is "mail.example.com" and is required to be the 1167 HostName in the client's SNI extension. The server certificate chain 1168 is required to be be signed by a trust anchor with the above 1169 certificate SHA2-256 digest. Finally, one of the DNS names in the 1170 server certificate is required to be be either "mail.example.com" or 1171 "example.com" (this additional name is a concession to compatibility 1172 with prior practice, see [I-D.ietf-dane-smtp-with-dane] for details). 1174 [RFC6125] specifies the semantics of wildcards in server certificates 1175 for various application protocols. DANE does not change how 1176 wildcards are treated by any given application. 1178 10.3. Design Considerations for Protocols Using DANE 1180 When a TLS client goes to the trouble of authenticating a certificate 1181 chain presented by a TLS server, it will typically not continue to 1182 use that server in the event of authentication failure, or else 1183 authentication serves no purpose. Some clients may, at times, 1184 operate in an "audit" mode, where authentication failure is reported 1185 to the user or in logs as a potential problem, but the connection 1186 proceeds despite the failure. Nevertheless, servers publishing TLSA 1187 records MUST be configured to allow correctly configured clients to 1188 successfully authenticate their TLS certificate chains. 1190 A service with DNSSEC-validated TLSA records implicitly promises TLS 1191 support. When all the TLSA records for a service are found 1192 "unusable", due to unsupported parameter combinations or malformed 1193 certificate association data, DANE clients cannot authenticate the 1194 service certificate chain. When authenticated TLS is mandatory, the 1195 client MUST NOT connect to the associated server. 1197 If, on the other hand, the use of TLS and DANE is "opportunistic" 1198 ([RFC7435]), then when all TLSA records are unusable, the client 1199 SHOULD connect to the server via an unauthenticated TLS connection, 1200 and if TLS encryption cannot be established, the client MUST NOT 1201 connect to the server. 1203 Standards for opportunistic DANE TLS specific to a particular 1204 application protocol may modify the above requirements. The key 1205 consideration is whether mandating the use of (unauthenticated) TLS 1206 even with unusable TLSA records is asking for more security than one 1207 can realistically expect. If expecting TLS support when unusable 1208 TLSA records are published is realistic for the application in 1209 question, then the application MUST avoid cleartext. If not 1210 realistic, then mandating TLS would cause clients (even in the 1211 absence of active attacks) to run into problems with various peers 1212 that do not interoperate "securely enough". That would create strong 1213 incentives to just disable opportunistic security and stick with 1214 cleartext. 1216 11. Note on DNSSEC Security 1218 Clearly the security of the DANE TLSA PKI rests on the security of 1219 the underlying DNSSEC infrastructure. While this document is not a 1220 guide to DNSSEC security, a few comments may be helpful to TLSA 1221 implementers. 1223 With the existing public CA Web PKI, name constraints are rarely 1224 used, and a public root CA can issue certificates for any domain of 1225 its choice. With DNSSEC, under the Registry/Registrar/Registrant 1226 model, the situation is different: only the registrar of record can 1227 update a domain's DS record in the registry parent zone (in some 1228 cases, however, the registry is the sole registrar). With many 1229 Generic Top Level Domains (gTLDs), for which multiple registrars 1230 compete to provide domains in a single registry, it is important to 1231 make sure that rogue registrars cannot easily initiate an 1232 unauthorized domain transfer, and thus take over DNSSEC for the 1233 domain. DNS Operators are advised to set a registrar lock on their 1234 domains to offer some protection against this possibility. 1236 When the registrar is also the DNS operator for the domain, one needs 1237 to consider whether the registrar will allow orderly migration of the 1238 domain to another registrar or DNS operator in a way that will 1239 maintain DNSSEC integrity. TLSA Publishers are advised to seek out a 1240 DNS hosting registrar that makes it possible to transfer domains to 1241 another hosting provider without disabling DNSSEC. 1243 DNSSEC signed RRsets cannot be securely revoked before they expire. 1244 Operators need to plan accordingly and not generate signatures of 1245 excessively long duration. For domains publishing high-value keys, a 1246 signature lifetime of a few days is reasonable, and the zone can be 1247 re-signed daily. For domains with less critical data, a reasonable 1248 signature lifetime is a couple of weeks to a month, and the zone can 1249 be re-signed weekly. 1251 Short signature lifetimes require tighter synchronization of primary 1252 and secondary nameservers, to make sure that secondary servers never 1253 serve records with expired signatures. They also limit the maximum 1254 time for which a primary server that signs the zone can be down. 1255 Therefore, short signature lifetimes are more appropriate for sites 1256 with dedicated operations staff, who can restore service quickly in 1257 case of a problem. 1259 Monitoring is important. If a DNS zone is not re-signed in a timely 1260 manner, a major outage is likely as the entire domain and all its 1261 sub-domains become "bogus". 1263 12. Summary of Updates to RFC6698 1265 o Section 3 updates [RFC6698] to specify a requirement for clients 1266 to support at least TLS 1.0, and to support SNI. 1268 o Section 5.1 updates [RFC6698] to specify peer identity matching 1269 and certificate validity interval based solely on the basis of the 1270 TLSA RRset. It also specifies DANE authentication of raw public 1271 keys [RFC7250] via TLSA records with Certificate Usage DANE-EE(3) 1272 and selector SPKI(1). 1274 o Section 5.2 updates [RFC6698] to require that servers publishing 1275 digest TLSA records with a usage of DANE-TA(2) MUST include the 1276 trust-anchor certificate in their TLS server certificate message. 1277 This extends to the case of "2 1 0" TLSA records which publish a 1278 full public key. 1280 o Section 5.3 and Section 5.4 explain that PKIX-EE(1) and PKIX-TA(0) 1281 are generally NOT RECOMMENDED. This document notes that with 1282 usage PKIX-TA(0) clients may need to process extended trust chains 1283 beyond the first trusted issuer, when that issuer is not self- 1284 signed. 1286 o Section 7 recommends that DANE application protocols specify that, 1287 when possible, securely CNAME expanded names be used to derive the 1288 TLSA base domain. 1290 o Section 8 specifies a strategy for managing TLSA records that 1291 interoperates with DANE clients regardless of what subset of the 1292 possible TLSA record types (combinations of TLSA parameters) is 1293 supported by the client. 1295 o Section 9 specifies a digest algorithm agility protocol. 1297 o Section 10.1 recommends against the use of Full(0) TLSA records, 1298 as digest records are generally much more compact. 1300 13. Operational Considerations 1302 The DNS time-to-live (TTL) of TLSA records needs to be chosen with 1303 care. When an unplanned change in the server's certificate chain and 1304 TLSA RRset is required, such as when keys are compromised or lost, 1305 clients that cache stale TLSA records will fail to validate the 1306 certificate chain of the updated server. Publish TLSA RRsets with 1307 TTLs that are short enough to limit unplanned service disruption to 1308 an acceptable duration. 1310 The signature validity period for TLSA records SHOULD NOT be too 1311 long. Signed DNSSEC records can be replayed by an MiTM attacker 1312 provided the signatures have not yet expired. Shorter signature 1313 validity periods allow for faster invalidation of compromised keys. 1314 Zone refresh and expiration times for secondary nameservers often 1315 imply a lower bound on the signature validity period (Section 11). 1316 See Section 4.4.1 of [RFC6781]. 1318 14. Security Considerations 1320 Application protocols that cannot make use of the existing public CA 1321 Web PKI, may choose to not implement certain TLSA record types 1322 defined in [RFC6698]. If such records are published despite not 1323 being supported by the application protocol, they are treated as 1324 "unusable". When TLS is opportunistic, the client MAY proceed to use 1325 the server with mandatory unauthenticated TLS. This is stronger than 1326 opportunistic TLS without DANE, since in that case the client may 1327 also proceed with a cleartext connection. When TLS is not 1328 opportunistic, the client MUST NOT connect to the server. 1330 Thus, when TLSA records are used with opportunistic protocols where 1331 the PKIX-TA(0) and PKIX-EE(1) do not apply, the recommended protocol 1332 design is for servers to not publish such TLSA records, and for 1333 opportunistic TLS clients to use them to only enforce the use of 1334 (albeit unauthenticated) TLS, but otherwise treat them as unusable. 1335 Of course, when PKIX-TA(0) and PKIX-EE(1) are supported by the 1336 application protocol, clients MUST implement these certificate usages 1337 as described in [RFC6698] and this document. 1339 15. IANA Considerations 1341 This specification requires no support from IANA. 1343 16. Acknowledgements 1345 The authors would like to thank Phil Pennock for his comments and 1346 advice on this document. 1348 Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded 1349 me into participating in DANE working group discussions. Thanks to 1350 Paul Hoffman who motivated me to produce this document and provided 1351 feedback on early drafts. Thanks also to Samuel Dukhovni for 1352 editorial assistance. 1354 17. References 1356 17.1. Normative References 1358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1359 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1360 RFC2119, March 1997, 1361 . 1363 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1364 Rose, "DNS Security Introduction and Requirements", RFC 1365 4033, DOI 10.17487/RFC4033, March 2005, 1366 . 1368 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1369 Rose, "Resource Records for the DNS Security Extensions", 1370 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1371 . 1373 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1374 Rose, "Protocol Modifications for the DNS Security 1375 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 1376 . 1378 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1379 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1380 RFC5246, August 2008, 1381 . 1383 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1384 Housley, R., and W. Polk, "Internet X.509 Public Key 1385 Infrastructure Certificate and Certificate Revocation List 1386 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1387 . 1389 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1390 Extensions: Extension Definitions", RFC 6066, DOI 1391 10.17487/RFC6066, January 2011, 1392 . 1394 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1395 Verification of Domain-Based Application Service Identity 1396 within Internet Public Key Infrastructure Using X.509 1397 (PKIX) Certificates in the Context of Transport Layer 1398 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1399 2011, . 1401 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1402 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1403 January 2012, . 1405 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1406 of Named Entities (DANE) Transport Layer Security (TLS) 1407 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1408 2012, . 1410 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 1411 Conversations about DNS-Based Authentication of Named 1412 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 1413 2014, . 1415 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1416 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1417 Transport Layer Security (TLS) and Datagram Transport 1418 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1419 June 2014, . 1421 17.2. Informative References 1423 [I-D.ietf-dane-smtp-with-dane] 1424 Dukhovni, V. and W. Hardaker, "SMTP security via 1425 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-19 1426 (work in progress), May 2015. 1428 [I-D.ietf-dane-srv] 1429 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 1430 Based Authentication of Named Entities (DANE) TLSA Records 1431 with SRV Records", draft-ietf-dane-srv-14 (work in 1432 progress), April 2015. 1434 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 1435 Operational Practices, Version 2", RFC 6781, DOI 10.17487/ 1436 RFC6781, December 2012, 1437 . 1439 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1440 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 1441 . 1443 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1444 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1445 December 2014, . 1447 Authors' Addresses 1449 Viktor Dukhovni 1450 Unaffiliated 1452 Email: ietf-dane@dukhovni.org 1453 Wes Hardaker 1454 Parsons 1455 P.O. Box 382 1456 Davis, CA 95617 1457 US 1459 Email: ietf@hardakers.net