idnits 2.17.1 draft-ietf-dane-ops-14.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 (July 27, 2015) is 3195 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: January 28, 2016 July 27, 2015 8 Updates to and Operational Guidance for the DANE Protocol 9 draft-ietf-dane-ops-14 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 January 28, 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 . . . . . . . . . . . . . . . . . . . 5 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 . . . 8 63 5.1. Certificate Usage DANE-EE(3) . . . . . . . . . . . . . . 9 64 5.2. Certificate Usage DANE-TA(2) . . . . . . . . . . . . . . 10 65 5.3. Certificate Usage PKIX-EE(1) . . . . . . . . . . . . . . 13 66 5.4. Certificate Usage PKIX-TA(0) . . . . . . . . . . . . . . 13 67 6. Service Provider and TLSA Publisher Synchronization . . . . . 14 68 7. TLSA Base Domain and CNAMEs . . . . . . . . . . . . . . . . . 16 69 8. TLSA Publisher Requirements . . . . . . . . . . . . . . . . . 17 70 8.1. Key rollover with fixed TLSA Parameters . . . . . . . . . 18 71 8.2. Switching to DANE-TA from DANE-EE . . . . . . . . . . . . 19 72 8.3. Switching to New TLSA Parameters . . . . . . . . . . . . 20 73 8.4. TLSA Publisher Requirements Summary . . . . . . . . . . . 20 74 9. Digest Algorithm Agility . . . . . . . . . . . . . . . . . . 21 75 10. General DANE Guidelines . . . . . . . . . . . . . . . . . . . 22 76 10.1. DANE DNS Record Size Guidelines . . . . . . . . . . . . 22 77 10.2. Certificate Name Check Conventions . . . . . . . . . . . 23 78 10.3. Design Considerations for Protocols Using DANE . . . . . 24 79 11. Note on DNSSEC Security . . . . . . . . . . . . . . . . . . . 25 80 12. Summary of Updates to RFC6698 . . . . . . . . . . . . . . . . 26 81 13. Operational Considerations . . . . . . . . . . . . . . . . . 26 82 14. Security Considerations . . . . . . . . . . . . . . . . . . . 27 83 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 84 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 85 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 86 17.1. Normative References . . . . . . . . . . . . . . . . . . 28 87 17.2. Informative References . . . . . . . . . . . . . . . . . 29 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 90 1. Introduction 92 The Transport Layer Security (TLS) [RFC5246] and Datagram Transport 93 Layer Security (DTLS) [RFC6347] protocols provide secured TCP and UDP 94 communication, respectively, over IP. In the context of this 95 document, channel security is assumed to be provided by TLS or DTLS. 97 By convention, "TLS" will be used throughout this document and, 98 unless otherwise specified, the text applies equally well to DTLS 99 over UDP. Used without authentication, TLS provides protection only 100 against eavesdropping through its use of encryption. With 101 authentication, TLS also provides integrity protection and 102 authentication, which protects the transport against man-in-the- 103 middle (MiTM) attacks. 105 The DNS-Based Authentication of Named Entities (DANE) specification 106 ([RFC6698]) introduces the DNS "TLSA" resource record type ("TLSA" is 107 not an acronym). TLSA records associate a certificate or a public 108 key of an end-entity or a trusted issuing authority with the 109 corresponding TLS transport endpoint. DANE relies on the DNS 110 Security Extensions (DNSSEC, [RFC4033]). DNSSEC validated DANE TLSA 111 records can be used to augment or replace the use of trusted public 112 Certification Authorities (CAs). 114 [RFC6698] defines three TLSA record fields with respectively 4, 2 and 115 3 currently specified values. These yield 24 distinct combinations 116 of TLSA record types. This document recommends a smaller set of 117 best-practice combinations of these fields to simplify protocol 118 design, implementation and deployment. 120 This document explains and recommends DANE-specific strategies to 121 simplify "virtual hosting", where a single Service Provider transport 122 endpoint simultaneously supports multiple hosted Customer Domains. 124 Other related documents that build on [RFC6698] are 125 [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]. 127 Section 12 summarizes the normative updates this document makes to 128 [RFC6698]. 130 1.1. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in 135 [RFC2119]. 137 The following terms are used throughout this document: 139 Web PKI: The Public Key Infrastructure (PKI) model employed by 140 browsers to authenticate web servers. This employs a set of 141 trusted public Certification Authorities (CAs) to vouch for the 142 authenticity of public keys associated with a particular party 143 (the subject). 145 Service Provider: A company or organization that offers to host a 146 service on behalf of the owner of a Customer Domain. The original 147 domain name associated with the service often remains under the 148 control of the customer. Connecting applications may be directed 149 to the Service Provider via a redirection resource record. 150 Example redirection records include MX, SRV, and CNAME. The 151 Service Provider frequently provides services for many customers 152 and needs to carefully manage any TLS credentials offered to 153 connecting applications to ensure name matching is handled easily 154 by the applications. 156 Customer Domain: As described above, a TLS client may be interacting 157 with a service that is hosted by a third party. This document 158 refers to the domain name used to locate the service (prior to any 159 redirection) as the "Customer Domain". 161 TLSA Publisher: The entity responsible for publishing a TLSA record 162 within a DNS zone. This zone will be assumed DNSSEC-signed and 163 validatable to a trust anchor, unless otherwise specified. If the 164 Customer Domain is not outsourcing their DNS service, the TLSA 165 Publisher will be the customer themselves. Otherwise, the TLSA 166 Publisher may be the operator of the outsourced DNS service. 168 public key: The term "public key" is short-hand for the 169 subjectPublicKeyInfo component of a PKIX [RFC5280] certificate. 171 SNI: The "Server Name Indication" (SNI) TLS protocol extension 172 allows a TLS client to request a connection to a particular 173 service name of a TLS server ([RFC6066], section 3). Without this 174 TLS extension, a TLS server has no choice but to offer a 175 certificate with a default list of server names, making it 176 difficult to host multiple Customer Domains at the same IP- 177 address-based TLS service endpoint (i.e., provide "secure virtual 178 hosting"). 180 TLSA parameters: In [RFC6698] the TLSA record is defined to consist 181 of four fields. The first three of these are numeric parameters 182 that specify the meaning of the data in the fourth and final 183 field. This document refers to the first three fields as "TLSA 184 parameters", or sometimes just "parameters" when obvious from 185 context. 187 TLSA base domain: Per Section 3 of [RFC6698] TLSA records are stored 188 at a DNS domain name which is a combination of a port and protocol 189 prefix and a "base domain". In [RFC6698] the "base domain" is the 190 fully qualified domain name of the TLS server. This document 191 modifies the TLSA record lookup strategy to prefer the fully CNAME 192 expanded name of the TLS server, provided that expansion is 193 "secure" (DNSSEC validated) at each stage of the expansion, and 194 TLSA records are published for this fully expanded name. Thus the 195 "TLSA base domain" is either the fully CNAME expanded TLS server 196 name, or otherwise the initial fully qualified TLS server name, 197 whichever is used in combination with a port and protocol prefix 198 to obtain the TLSA RRset. 200 2. DANE TLSA Record Overview 202 DANE TLSA [RFC6698] specifies a protocol for publishing TLS server 203 certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035]. 204 The DANE TLSA specification defines multiple TLSA RR types via 205 combinations of numeric values of the first three fields of the TLSA 206 record (i.e. the "TLSA parameters"). The numeric values of these 207 parameters were later given symbolic names in [RFC7218]. These 208 parameters are: 210 The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies 4 211 values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3). There 212 is an additional private-use value: PrivCert(255), which, given 213 its private scope, shall not be considered further in this 214 document. All other values are reserved for use by future 215 specifications. 217 The selector field: Section 2.1.2 of [RFC6698] specifies 2 values: 218 Cert(0), SPKI(1). There is an additional private-use value: 219 PrivSel(255). All other values are reserved for use by future 220 specifications. 222 The matching type field: Section 2.1.3 of [RFC6698] specifies 3 223 values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional 224 private-use value: PrivMatch(255). All other values are reserved 225 for use by future specifications. 227 In the matching type field, of the two digest algorithms, for now 228 only SHA2-256(1) is mandatory to implement. Clients SHOULD implement 229 SHA2-512(2), but servers SHOULD NOT exclusively publish SHA2-512(2) 230 digests. The digest algorithm agility protocol defined in Section 9 231 SHOULD be used by clients to decide how to process TLSA RRsets that 232 employ multiple digest algorithms. Server operators MUST publish 233 TLSA RRsets that are compatible (see Section 8) with digest algorithm 234 agility (Section 9). 236 2.1. Example TLSA record 238 In the example TLSA record below: 240 _25._tcp.mail.example.com. IN TLSA 2 0 1 ( 241 E8B54E0B4BAA815B06D3462D65FBC7C0 242 CF556ECCF9F5303EBFBB77D022F834C0 ) 244 The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and 245 the matching type is SHA2-256(1). The last field is the Certificate 246 Association Data Field, which in this case contains the SHA2-256 247 digest of the server certificate. 249 3. DANE TLS Requirements 251 [RFC6698] does not discuss what versions of TLS are required when 252 using DANE records. This document specifies that TLS clients that 253 support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support 254 TLS 1.2 or later. 256 TLS clients using DANE MUST support the "Server Name Indication" 257 (SNI) extension of TLS ([RFC6066]). Servers MAY support SNI and 258 respond with a matching certificate chain, but MAY also ignore SNI 259 and respond with a default certificate chain. When a servers does 260 support SNI, but is not configured with a certificate chain that 261 exactly matches the client's SNI extension, SHOULD respond with some 262 other (default or closest match) certificate chain, since clients may 263 support more than one server name, but can only put a single name in 264 the SNI extension. 266 4. DANE Certificate Usage Selection Guidelines 268 As mentioned in Section 2, the TLSA certificate usage field takes one 269 of four possible values. With PKIX-TA(0) and PKIX-EE(1), the 270 validation of peer certificate chains requires additional pre- 271 configured CA trust anchors that are mutually trusted by the 272 operators of the TLS server and client. With DANE-TA(2) and DANE- 273 EE(3), no pre-configured CA trust anchors are required and the 274 published DANE TLSA records are sufficient to verify the peer's 275 certificate chain. 277 Protocol designers need to carefully consider which set of DANE 278 certificate usages to support. Simultaneous support for all four 279 usages is NOT RECOMMENDED for DANE clients. Protocol designers are 280 encouraged to specify use of either the PKIX-TA(0) and PKIX-EE(1) 281 certificate usages, or the use of the DANE-TA(2) and DANE-EE(3) 282 usages. When all four usages are supported, an attacker capable of 283 compromising the integrity of DNSSEC needs only to replace server's 284 TLSA RRset with one that lists suitable DANE-EE(3) or DANE-TA(2) 285 records, effectively bypassing an added verification via public CAs. 286 In other words, when all four usages are supported, PKIX-TA(2) and 287 PKIX-EE(1) offer only illusory incremental security over DANE-TA(2) 288 and DANE-EE(3). 290 Designs in which clients support just the DANE-TA(2) and DANE-EE(3) 291 certificate usages are generally RECOMMENDED. With DANE-TA(2) and 292 DANE-EE(3) clients don't need to track a large changing list of X.509 293 trust-anchors in order to successfully authenticate servers whose 294 certificates are issued by a brand new or not widely trusted CA. 296 The DNSSEC TLSA records for servers MAY include both sets of usages 297 if the server needs to support a mixture of clients; some supporting 298 one pair of usages and some the other. 300 4.1. Opportunistic Security and PKIX usages 302 When the client's protocol design is based on Opportunistic Security 303 (OS, [RFC7435]), and the use of authentication is based on the 304 presence of server TLSA records, it is especially important to avoid 305 the PKIX-EE(1) and PKIX-TA(0) certificate usages. 307 When authenticated TLS is used opportunistically, based on the 308 presence of DANE TLSA records, and no usable secure TLSA records are 309 present, unauthenticated TLS is used if possible, and otherwise 310 perhaps even cleartext. If however, usable secure TLSA records are 311 published, authentication must succeed. Also, outside the browser 312 space, there is no pre-ordained canon of trusted CAs, and in any case 313 there is no security advantage in using PKIX-TA(0) or PKIX-EE(1) when 314 the DANE-TA(2) and DANE-EE(3) usages are also supported (as an 315 attacker who can compromise DNS can replace the former with the 316 latter). 318 Authentication via the PKIX-TA(0) and PKIX-EE(1) certificate usages 319 is more brittle, the client and server need to happen to agree on a 320 mutually trusted CA, but with opportunistic security the client is 321 just trying to protect the communication channel at the request of 322 the server, and would otherwise be willing to use cleartext or 323 unauthenticated TLS. Use of fragile mechanisms (like public CA 324 authentication for some unspecified set of trusted CAs) is not 325 sufficiently reliable for an opportunistic security client to honor 326 the server's request for authentication. Opportunistic security 327 needs to be unintrusive and to require few, if any, work-arounds for 328 valid and yet mismatched peers. 330 With the PKIX-TA(0) and PKIX-EE(1) usages offering no more security, 331 but being more prone to failure, they are a poor fit for 332 opportunistic security and SHOULD NOT be used in that context. 334 4.2. Interaction with Certificate Transparency 336 Certificate Transparency (CT) [RFC6962] defines an experimental 337 approach that could be used to mitigate the risk of rogue or 338 compromised public CAs issuing unauthorized certificates. This 339 section clarifies the interaction of the experimental CT and DANE. 340 This section may need to be revised in light of any future standards 341 track version of CT. 343 When a server is authenticated via a DANE TLSA RR with TLSA 344 Certificate Usage DANE-EE(3), the domain owner has directly specified 345 the certificate associated with the given service without reference 346 to any public certification authority. Therefore, when a TLS client 347 authenticates the TLS server via a TLSA record with usage DANE-EE(3), 348 CT checks SHOULD NOT be performed. Publication of the server 349 certificate or public key (digest) in a TLSA record in a DNSSEC 350 signed zone by the domain owner assures the TLS client that the 351 certificate is not an unauthorized certificate issued by a rogue CA 352 without the domain owner's consent. 354 When a server is authenticated via a DANE TLSA record with TLSA usage 355 DANE-TA(2) and the server certificate does not chain to a known 356 public root CA, CT cannot apply (CT logs only accept chains that 357 start with a known, public root). Since TLSA Certificate Usage DANE- 358 TA(2) is generally intended to support non-public trust anchors, TLS 359 clients SHOULD NOT perform CT checks with usage DANE-TA(2). 361 4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE 363 The choice of preferred certificate usages may need to change as a 364 protocol evolves. When transitioning between PKIX-TA/PKIX-EE and 365 DANE-TA/DANE-EE, clients begin to enable support for the new 366 certificate usage values. If the new preferred certificate usages 367 are PKIX-TA/EE this requires installing and managing the appropriate 368 set of CA trust anchors. During this time servers will publish both 369 types of TLSA records. At some later time when the vast majority of 370 servers have published the new preferred TLSA records, clients can 371 stop supporting the legacy certificate usages. Similarly, servers 372 can stop publishing legacy TLSA records once the vast majority of 373 clients support the new certificate usages. 375 5. Certificate-Usage-Specific DANE Updates and Guidelines 377 The four Certificate Usage values from the TLSA record, DANE-EE(3), 378 DANE-TA(2), PKIX-EE(1) and PKIX-TA(0), are discussed below. 380 5.1. Certificate Usage DANE-EE(3) 382 In this section the meaning of DANE-EE(3) is updated from [RFC6698] 383 to specify that peer identity matching and that validity period 384 enforcement is based solely on the TLSA RRset properties. This 385 document also extends [RFC6698] to cover the use of DANE 386 authentication of raw public keys [RFC7250] via TLSA records with 387 Certificate Usage DANE-EE(3) and selector SPKI(1). 389 Authentication via certificate usage DANE-EE(3) TLSA records involves 390 simply checking that the server's leaf certificate matches the TLSA 391 record. In particular, the binding of the server public key to its 392 name is based entirely on the TLSA record association. The server 393 MUST be considered authenticated even if none of the names in the 394 certificate match the client's reference identity for the server. 396 Similarly, with DANE-EE(3), the expiration date of the server 397 certificate MUST be ignored. The validity period of the TLSA record 398 key binding is determined by the validity period of the TLSA record 399 DNSSEC signatures. 401 If a server uses just DANE-EE(3) TLSA records, and all its clients 402 are DANE clients, the server need not employ SNI (i.e., it may ignore 403 the client's SNI message) even when the server is known via multiple 404 domain names that would otherwise require separate certificates. It 405 is instead sufficient for the TLSA RRsets for all the domain names in 406 question to match the server's default certificate. For application 407 protocols where the server name is obtained indirectly via SRV, MX or 408 similar records, it is simplest to publish a single hostname as the 409 target server name for all the hosted domains. 411 In organizations where it is practical to make coordinated changes in 412 DNS TLSA records before server key rotation, it is generally best to 413 publish end-entity DANE-EE(3) certificate associations in preference 414 to other choices of certificate usage. DANE-EE(3) TLSA records 415 support multiple server names without SNI, don't suddenly stop 416 working when leaf or intermediate certificates expire, and don't fail 417 when a server operator neglects to include all the required issuer 418 certificates in the server certificate chain. 420 TLSA records published for DANE servers should, as a best practice, 421 be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE 422 implementations are required to support SHA2-256, this record type 423 works for all clients and need not change across certificate renewals 424 with the same key. This TLSA record type easily supports hosting 425 arrangements with a single certificate matching all hosted domains. 426 It is also the easiest to implement correctly in the client. 428 Another advantage of "DANE-EE(3) SPKI(1)" (with any suitable matching 429 type) TLSA records is that they are compatible with the raw public 430 key TLS extension specified in [RFC7250]. DANE clients that support 431 this extension can use the TLSA record to authenticate servers that 432 negotiate the use of raw public keys in place of X.509 certificate 433 chains. Provided the server adheres to the requirements of 434 Section 8, the fact that raw public keys are not compatible with any 435 other TLSA record types will not get in the way of successful 436 authentication. Clients that employ DANE to authenticate the peer 437 server SHOULD NOT negotiate the use of raw public keys unless the 438 server's TLSA RRset includes compatible TLSA records. 440 While it is, in principle, also possible to authenticate raw public 441 keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the 442 public key from the certificate in DNS, extracting just the the 443 public key from a "3 0 0" TLSA record requires extra logic on clients 444 that not all implementations are expected to provide. Servers that 445 wish to support [RFC7250] raw public keys need to publish TLSA 446 records with a certificate usage of DANE-EE(3) and a selector of 447 SPKI(1). 449 5.2. Certificate Usage DANE-TA(2) 451 This section updates [RFC6698] by specifying a new operational 452 requirement for servers publishing TLSA records with a usage of DANE- 453 TA(2): such servers MUST include the trust-anchor certificate in 454 their TLS server certificate message unless all such TLSA records are 455 "2 0 0" records that publish the server certificate in full. 457 Some domains may prefer to avoid the operational complexity of 458 publishing unique TLSA RRs for each TLS service. If the domain 459 employs a common issuing Certification Authority to create 460 certificates for multiple TLS services, it may be simpler to publish 461 the issuing authority as a trust anchor (TA) for the certificate 462 chains of all relevant services. The TLSA query domain (TLSA base 463 domain with port and protocol prefix labels) for each service issued 464 by the same TA may then be set to a CNAME alias that points to a 465 common TLSA RRset that matches the TA. For example: 467 www1.example.com. IN A 192.0.2.1 468 www2.example.com. IN A 192.0.2.2 469 _443._tcp.www1.example.com. IN CNAME tlsa201._dane.example.com. 470 _443._tcp.www2.example.com. IN CNAME tlsa201._dane.example.com. 471 tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14... 473 With usage DANE-TA(2) the server certificates will need to have names 474 that match one of the client's reference identifiers (see [RFC6125]). 475 When hosting multiple unrelated client domains (that can't all appear 476 in a single certificate), such a server SHOULD employ SNI to select 477 the appropriate certificate to present to the client. 479 5.2.1. Recommended record combinations 481 TLSA records with matching type Full(0) are NOT RECOMMENDED. While 482 these potentially obviate the need to transmit the TA certificate in 483 the TLS server certificate message, client implementations may not be 484 able to augment the server certificate chain with the data obtained 485 from DNS, especially when the TLSA record supplies a bare key 486 (selector SPKI(1)). Since the server will need to transmit the TA 487 certificate in any case, server operators SHOULD publish TLSA records 488 with a matching type other than Full(0) and avoid potential DNS 489 interoperability issues with large TLSA records containing full 490 certificates or keys (see Section 10.1.1). 492 TLSA Publishers employing DANE-TA(2) records SHOULD publish records 493 with a selector of Cert(0). Such TLSA records are associated with 494 the whole trust anchor certificate, not just with the trust anchor 495 public key. In particular, when authenticating the peer certificate 496 chain via such a TLSA record, the client SHOULD apply any relevant 497 constraints from the trust anchor certificate, such as, for example, 498 path length constraints. 500 While a selector of SPKI(1) may also be employed, the resulting TLSA 501 record will not specify the full trust anchor certificate content, 502 and elements of the trust anchor certificate other than the public 503 key become mutable. This may, for example, enable a subsidiary CA to 504 issue a chain that violates the trust anchor's path length or name 505 constraints. 507 5.2.2. Trust anchor digests and server certificate chain 509 With DANE-TA(2), a complication arises when the TA certificate is 510 omitted from the server's certificate chain, perhaps on the basis of 511 Section 7.4.2 of [RFC5246]: 513 The sender's certificate MUST come first in the list. Each 514 following certificate MUST directly certify the one preceding 515 it. Because certificate validation requires that root keys be 516 distributed independently, the self-signed certificate that 517 specifies the root certification authority MAY be omitted from 518 the chain, under the assumption that the remote end must 519 already possess it in order to validate it in any case. 521 With TLSA Certificate Usage DANE-TA(2), there is no expectation that 522 the client is pre-configured with the trust anchor certificate. In 523 fact, client implementations are free to ignore all locally 524 configured trust anchors when processing usage DANE-TA(2) TLSA 525 records and may rely exclusively on the certificates provided in the 526 server's certificate chain. But, with a digest in the TLSA record, 527 the TLSA record contains neither the full trust anchor certificate 528 nor the full public key. If the TLS server's certificate chain does 529 not contain the trust anchor certificate, DANE clients will be unable 530 to authenticate the server. 532 TLSA Publishers that publish TLSA Certificate Usage DANE-TA(2) 533 associations with a selector of SPKI(1) or using a digest-based 534 matching type (not Full(0)) MUST ensure that the corresponding server 535 is configured to also include the trust anchor certificate in its TLS 536 handshake certificate chain, even if that certificate is a self- 537 signed root CA and would have been optional in the context of the 538 existing public CA PKI. 540 Only when the server TLSA record includes a "DANE-TA(2) Cert(0) 541 Full(0)" TLSA record containing a full trust-anchor certificate, is 542 the trust-anchor certificate optional in the server's TLS certificate 543 message. Only in this case, the client MUST be able to verify the 544 server's certificate chain via a trust-anchor provided via DNS or via 545 the TLS handshake. 547 5.2.3. Trust anchor public keys 549 TLSA records with TLSA Certificate Usage DANE-TA(2), selector SPKI(1) 550 and a matching type of Full(0) publish the full public key of a trust 551 anchor via DNS. In section 6.1.1 of [RFC5280] the definition of a 552 trust anchor consists of the following four parts: 554 1. the trusted issuer name, 556 2. the trusted public key algorithm, 558 3. the trusted public key, and 560 4. optionally, the trusted public key parameters associated with the 561 public key. 563 Items 2-4 are precisely the contents of the subjectPublicKeyInfo 564 published in the TLSA record. The issuer name is not included in the 565 subjectPublicKeyInfo. 567 With TLSA Certificate Usage DANE-TA(2), the client may not have the 568 associated trust anchor certificate, and cannot generally verify 569 whether a particular certificate chain is "issued by" the trust 570 anchor described in the TLSA record. 572 When the server certificate chain includes a CA certificate whose 573 public key matches the TLSA record, the client can match that CA as 574 the intended issuer. Otherwise, the client can only check that the 575 topmost certificate in the server's chain is "signed by" the trust 576 anchor's public key in the TLSA record. Such a check may be 577 difficult to implement, and cannot be expected to be supported by all 578 clients. 580 Thus, servers cannot rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA 581 records to be sufficient to authenticate chains issued by the 582 associated public key in the absence of a corresponding certificate 583 in the server's TLS certificate message. Servers employing "2 1 0" 584 TLSA records, MUST include the corresponding trust-anchor certificate 585 in their certificate chain. 587 If none of the server's certificate chain elements match a public key 588 specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1) 589 Full(0)" TLSA record is available, it is RECOMMENDED that clients 590 check whether the topmost certificate in the chain is signed by the 591 provided public key and has not expired, and in that case consider 592 the server authenticated, provided the rest of the chain passes 593 validation including leaf certificate name checks. 595 5.3. Certificate Usage PKIX-EE(1) 597 This Certificate Usage is similar to DANE-EE(3), but in addition PKIX 598 verification is required. Therefore, name checks, certificate 599 expiration, etc., apply as they would without DANE. 601 5.4. Certificate Usage PKIX-TA(0) 603 This section updates [RFC6698] by specifying new client 604 implementation requirements. Clients that trust intermediate 605 certificates MUST be prepared to construct longer PKIX chains than 606 would be required for PKIX alone. 608 TLSA Certificate Usage PKIX-TA(0) allows a domain to publish 609 constraints on the set of PKIX certification authorities trusted to 610 issue certificates for its TLS servers. This TLSA record matches 611 PKIX-verified trust chains which contain an issuer certificate (root 612 or intermediate) that matches its association data field (typically a 613 certificate or digest). 615 PKIX-TA(0) also requires more complex coordination between the 616 Customer Domain and the Service Provider in hosting arrangements. 617 Thus, this certificate usage is NOT RECOMMENDED when the Service 618 Provider is not also the TLSA Publisher. 620 TLSA Publishers who publish TLSA records for a particular public root 621 CA, will expect that clients will only accept chains anchored at that 622 root. It is possible, however, that the client's trusted certificate 623 store includes some intermediate CAs, either with or without the 624 corresponding root CA. When a client constructs a trust chain 625 leading from a trusted intermediate CA to the server leaf 626 certificate, such a "truncated" chain might not contain the trusted 627 root published in the server's TLSA record. 629 If the omitted root is also trusted, the client may erroneously 630 reject the server chain if it fails to determine that the shorter 631 chain it constructed extends to a longer trusted chain that matches 632 the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record, 633 while no matching certificate is found, a client MUST continue 634 extending the chain even after any locally trusted certificate is 635 found. If no TLSA records have matched any of the elements of the 636 chain, and the trusted certificate found is not self-issued, the 637 client MUST attempt to build a longer chain in case a certificate 638 closer to the root matches the server's TLSA record. 640 6. Service Provider and TLSA Publisher Synchronization 642 Whenever possible, the TLSA Publisher and the Service Provider should 643 be the same entity. Otherwise, they need to coordinate changes to 644 ensure that TLSA records published by the TLSA Publisher don't fall 645 out of sync with the server certificate used by the Service Provider. 646 Such coordination is difficult and service outages will result when 647 coordination fails. 649 Publishing the TLSA record in the Service Provider's zone avoids the 650 complexity of bilateral coordination of server certificate 651 configuration and TLSA record management. Even when the TLSA RRset 652 has to be published in the Customer Domain's DNS zone (perhaps the 653 client application does not "chase" CNAMEs to the TLSA base domain), 654 it is possible to employ CNAME records to delegate the content of the 655 TLSA RRset to a domain operated by the Service Provider. 657 Only Certificate Usages DANE-EE(3) and DANE-TA(2) work well with TLSA 658 CNAMEs across organizational boundaries. With PKIX-TA(0) or PKIX- 659 EE(1) the Service Provider would need to obtain certificates in the 660 name of Customer Domain from a suitable public CA (securely 661 impersonate the customer), or the customer would need to provision 662 the relevant private keys and certificates at the Service Provider's 663 systems. 665 Certificate Usage DANE-EE(3): In this case the Service Provider can 666 publish a single TLSA RRset that matches the server certificate or 667 public key digest. The same RRset works for all Customer Domains 668 because name checks do not apply with DANE-EE(3) TLSA records (see 669 Section 5.1). A Customer Domain can create a CNAME record 670 pointing to the TLSA RRset published by the Service Provider. 672 Certificate Usage DANE-TA(2): When the Service Provider operates a 673 private certification authority, the Service Provider is free to 674 issue a certificate bearing any customer's domain name. Without 675 DANE, such a certificate would not pass trust verification, but 676 with DANE, the customer's TLSA RRset that is aliased to the 677 provider's TLSA RRset can delegate authority to the provider's CA 678 for the corresponding service. The Service Provider can generate 679 appropriate certificates for each customer and use the SNI 680 information provided by clients to select the right certificate 681 chain to present to each client. 683 Below are example DNS records (assumed "secure" and shown without the 684 associated DNSSEC information, such as record signatures) that 685 illustrate both of of the above models in the case of an HTTPS 686 service whose clients all support DANE TLS. These examples work even 687 with clients that don't "chase" CNAMEs when constructing the TLSA 688 base domain (see Section 7 below). 690 ; The hosted web service is redirected via a CNAME alias. 691 ; The associated TLSA RRset is also redirected via a CNAME alias. 692 ; 693 ; A single certificate at the provider works for all Customer 694 ; Domains due to the use of the DANE-EE(3) Certificate Usage. 695 ; 696 www1.example.com. IN CNAME w1.example.net. 697 _443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net. 698 _443._tcp.w1.example.net. IN TLSA 3 1 1 ( 699 8A9A70596E869BED72C69D97A8895DFA 700 D86F300A343FECEFF19E89C27C896BC9 ) 702 ; 703 ; A CA at the provider can also issue certificates for each Customer 704 ; Domain, and use the DANE-TA(2) Certificate Usage type to 705 ; indicate a trust anchor. 706 ; 707 www2.example.com. IN CNAME w2.example.net. 708 _443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net. 709 _443._tcp.w2.example.net. IN TLSA 2 0 1 ( 710 C164B2C3F36D068D42A6138E446152F5 711 68615F28C69BD96A73E354CAC88ED00C ) 713 With protocols that support explicit transport redirection via DNS MX 714 records, SRV records, or other similar records, the TLSA base domain 715 is based on the redirected transport end-point, rather than the 716 origin domain. With SMTP, for example, when an email service is 717 hosted by a Service Provider, the Customer Domain's MX hostnames will 718 point at the Service Provider's SMTP hosts. When the Customer 719 Domain's DNS zone is signed, the MX hostnames can be securely used as 720 the base domains for TLSA records that are published and managed by 721 the Service Provider. For example (without the required DNSSEC 722 information, such as record signatures): 724 ; Hosted SMTP service 725 ; 726 example.com. IN MX 0 mx1.example.net. 727 example.com. IN MX 0 mx2.example.net. 728 _25._tcp.mx1.example.net. IN TLSA 3 1 1 ( 729 8A9A70596E869BED72C69D97A8895DFA 730 D86F300A343FECEFF19E89C27C896BC9 ) 731 _25._tcp.mx2.example.net. IN TLSA 3 1 1 ( 732 C164B2C3F36D068D42A6138E446152F5 733 68615F28C69BD96A73E354CAC88ED00C ) 735 If redirection to the Service Provider's domain (via MX or SRV 736 records or any similar mechanism) is not possible, and aliasing of 737 the TLSA record is not an option, then more complex coordination 738 between the Customer Domain and Service Provider will be required. 739 Either the Customer Domain periodically provides private keys and a 740 corresponding certificate chain to the Provider (after making 741 appropriate changes in its TLSA records), or the Service Provider 742 periodically generates the keys and certificates and needs to wait 743 for matching TLSA records to be published by its Customer Domains 744 before deploying newly generated keys and certificate chains. 745 Section 7 below describes an approach that employs CNAME "chasing" to 746 avoid the difficulties of coordinating key management across 747 organization boundaries. 749 For further information about combining DANE and SRV, please see 750 [I-D.ietf-dane-srv]. 752 7. TLSA Base Domain and CNAMEs 754 When the application protocol does not support service location 755 indirection via MX, SRV or similar DNS records, the service may be 756 redirected via a CNAME. A CNAME is a more blunt instrument for this 757 purpose, since unlike an MX or SRV record, it remaps the entire 758 origin domain to the target domain for all protocols. 760 The complexity of coordinating key management is largely eliminated 761 when DANE TLSA records are found in the Service Provider's domain, as 762 discussed in Section 6. Therefore, DANE TLS clients connecting to a 763 server whose domain name is a CNAME alias SHOULD follow the CNAME 764 hop-by-hop to its ultimate target host (noting at each step whether 765 the CNAME is DNSSEC-validated). If at each stage of CNAME expansion 766 the DNSSEC validation status is "secure", the final target name 767 SHOULD be the preferred base domain for TLSA lookups. 769 Implementations failing to find a TLSA record using a base name of 770 the final target of a CNAME expansion SHOULD issue a TLSA query using 771 the original destination name. That is, the preferred TLSA base 772 domain SHOULD be derived from the fully expanded name, and failing 773 that SHOULD be the initial domain name. 775 When the TLSA base domain is the result of "secure" CNAME expansion, 776 the resulting domain name MUST be used as the HostName in the 777 client's SNI extension, and MUST be the primary reference identifier 778 for peer certificate matching with certificate usages other than 779 DANE-EE(3). 781 Protocol-specific TLSA specifications may provide additional guidance 782 or restrictions when following CNAME expansions. 784 Though CNAMEs are illegal on the right hand side of most indirection 785 records, such as MX and SRV records, they are supported by some 786 implementations. For example, if the MX or SRV host is a CNAME 787 alias, some implementations may "chase" the CNAME. If they do, they 788 SHOULD use the target hostname as the preferred TLSA base domain as 789 described above (and if the TLSA records are found there, use the 790 CNAME expanded domain also in SNI and certificate name checks). 792 8. TLSA Publisher Requirements 794 This section updates [RFC6698] by specifying a requirement on the 795 TLSA Publisher to ensure that each combination of Certificate Usage, 796 selector and matching type in the server's TLSA RRset MUST include at 797 least one record that matches the server's current certificate chain. 798 TLSA records that match recently retired or yet to be deployed 799 certificate chains will be present during key rollover. Such past or 800 future records MUST NOT at any time be the only records published for 801 any given combination of usage, selector and matching type. The TLSA 802 record update process described below ensures that this requirement 803 is met. 805 While a server is to be considered authenticated when its certificate 806 chain is matched by any of the published TLSA records, not all 807 clients support all combinations of TLSA record parameters. Some 808 clients may not support some digest algorithms, others may either not 809 support, or may exclusively support, the PKIX Certificate Usages. 810 Some clients may prefer to negotiate [RFC7250] raw public keys, which 811 are only compatible with TLSA records whose Certificate Usage is 812 DANE-EE(3) with selector SPKI(1). the only other TLSA record type 813 that is potentially compatible with raw public keys is DANE-EE(3) 814 Cert(0) Full(0), but support for raw public keys with that TLSA 815 record type is not expected to be broadly implemented. 817 A consequence of the above uncertainty as to which TLSA parameters 818 are supported by any given client is that servers need to ensure that 819 each and every parameter combination that appears in the TLSA RRset 820 is, on its own, sufficient to match the server's current certificate 821 chain. In particular, when deploying new keys or new parameter 822 combinations some care is required to not generate parameter 823 combinations that only match past or future certificate chains (or 824 raw public keys). The rest of this section explains how to update 825 the TLSA RRset in a manner that ensures the above requirement is met. 827 8.1. Key rollover with fixed TLSA Parameters 829 The simplest case is key rollover while retaining the same set of 830 published parameter combinations. In this case, TLSA records 831 matching the existing server certificate chain (or raw public keys) 832 are first augmented with corresponding records matching the future 833 keys, at least two TTLs or longer before the the new chain is 834 deployed. This allows the obsolete RRset to age out of client caches 835 before the new chain is used in TLS handshakes. Once sufficient time 836 has elapsed and all clients performing DNS lookups are retrieving the 837 updated TLSA records, the server administrator may deploy the new 838 certificate chain, verify that it works, and then remove any obsolete 839 records matching the no longer active chain: 841 ; Initial TLSA RRset 842 ; 843 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 845 ; Transitional TLSA RRset published at least 2*TTL seconds 846 ; before the actual key change 847 ; 848 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 849 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 851 ; Final TLSA RRset after the key change 852 ; 853 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 855 The next case to consider is adding or switching to a new combination 856 of TLSA parameters. In this case publish the new parameter 857 combinations for the server's existing certificate chain first, and 858 only then deploy new keys if desired: 860 ; Initial TLSA RRset 861 ; 862 _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46... 864 ; New TLSA RRset, same key re-published as DANE-EE(3) 865 ; 866 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 868 8.2. Switching to DANE-TA from DANE-EE 870 This section explains how to migrate to a new certificate chain and 871 TLSA record with usage DANE-TA(2) from a self-signed server 872 certificate and a DANE-EE(3) SPKI(1) SHA2-256(1) TLSA record. This 873 example assumes that a new private key is generated in conjunction 874 with transitioning to a new certificate issued by the desired trust- 875 anchor. 877 The original "3 1 1" TLSA record supports [RFC7250] raw public keys, 878 and clients may choose to negotiate their use. Use of raw public 879 keys rules out the possibility of certificate chain verification. 880 Therefore, the transitional TLSA record for the planned DANE-TA(2) 881 certificate chain is a "3 1 1" record that works even when raw public 882 keys are used. The TLSA RRset is updated to use DANE-TA(2) only 883 after the new chain is deployed and the "3 1 1" record matching the 884 original key is dropped. 886 This process follows the requirement that each combination of 887 parameters present in the RRset is always sufficient to validate the 888 server. It avoids publishing a transitional TLSA RRset in which "3 1 889 1" matches only the current key and "2 0 1" matches only the future 890 certificate chain, because these might not work reliably during the 891 initial deployment of the new keys. 893 ; Initial TLSA RRset 894 ; 895 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 897 ; Transitional TLSA RRset, published at least 2*TTL before the 898 ; actual key change. The new keys are issued by a DANE-TA(2) CA, 899 ; but are initially specified via a DANE-EE(3) association. 900 ; 901 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 902 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 904 ; The final TLSA RRset after the key change. Now that the old 905 ; self-signed EE key is out of the picture, publish the issuing 906 ; TA of the new chain. 907 ; 908 _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d... 910 8.3. Switching to New TLSA Parameters 912 When employing a new digest algorithm in the TLSA RRset, for 913 compatibility with digest agility specified in Section 9 below, 914 administrators SHOULD publish the new digest algorithm with each 915 combination of Certificate Usage and selector for each associated key 916 or chain used with any other digest algorithm. When removing an 917 algorithm, remove it entirely. Each digest algorithm employed SHOULD 918 match the same set of chains (or raw public keys). 920 ; Initial TLSA RRset with DANE-EE SHA2-256 associations for two keys. 921 ; 922 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 923 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 925 ; New TLSA RRset also with SHA2-512 associations for each key 926 ; 927 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 928 _443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc... 929 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 930 _443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714... 932 8.4. TLSA Publisher Requirements Summary 934 In summary, server operators updating TLSA records should make one 935 change at a time. The individual safe changes are: 937 o Pre-publish new certificate associations that employ the same TLSA 938 parameters (usage, selector and matching type) as existing TLSA 939 records, but match certificate chains that will be deployed in the 940 near future. 942 o Wait for stale TLSA RRsets to expire from DNS caches before 943 configuring servers to use the new certificate chain. 945 o Remove TLSA records matching no longer deployed certificate 946 chains. 948 o Publish TLSA RRsets in which all parameter combinations 949 (certificate usage, selector and matching type) present in the 950 RRset match the same set of current and planned certificate 951 chains. 953 The above steps are intended to ensure that at all times and for each 954 combination of usage, selector and matching type at least one TLSA 955 record corresponds to the server's current certificate chain. Each 956 combination of Certificate Usage, selector and matching type in a 957 server's TLSA RRset SHOULD NOT at any time (including unexpired 958 RRsets in client caches) match only some combination of future or 959 past certificate chains. As a result, no matter what combinations of 960 usage, selector and matching type may be supported by a given client, 961 they will be sufficient to authenticate the server. 963 9. Digest Algorithm Agility 965 While [RFC6698] specifies multiple digest algorithms, it does not 966 specify a protocol by which the client and TLSA record publisher can 967 agree on the strongest shared algorithm. Such a protocol would allow 968 the client and server to avoid exposure to deprecated weaker 969 algorithms that are published for compatibility with less capable 970 clients, but which SHOULD be avoided when possible. Such a protocol 971 is specified below. 973 This section defines a protocol for avoiding deprecated digest 974 algorithms when these are published in a peer's TLSA RRset alongside 975 stronger digest algorithms. Note that this protocol never avoids RRs 976 with DANE matching type Full(0), as these do not employ a digest 977 algorithm that might some day be weakened by cryptanalysis. 979 Client implementations SHOULD implement a default order of digest 980 algorithms by strength. This order SHOULD be configurable by the 981 administrator or user of the client software. If possible, a 982 configurable mapping from numeric DANE TLSA matching types to 983 underlying digest algorithms provided by the cryptographic library 984 SHOULD be implemented to allow new matching types to be used with 985 software that predates their introduction. Configurable ordering of 986 digest algorithms SHOULD be extensible to any new digest algorithms. 988 To make digest algorithm agility possible, all published DANE TLSA 989 RRsets MUST conform to the requirements of Section 8. Clients SHOULD 990 use digest algorithm agility when processing the peer's DANE TLSA 991 records. Algorithm agility is to be applied after first discarding 992 any unusable or malformed records (unsupported digest algorithm, or 993 incorrect digest length). For each usage and selector, the client 994 SHOULD process only any usable records with a matching type of 995 Full(0) and the usable records whose digest algorithm is considered 996 by the client to be the strongest among usable records with the given 997 usage and selector. 999 Example: a client implements digest agility and prefers SHA2-512(2) 1000 over SHA2-256(1), while the server publishes an RRset that employs 1001 both digest algorithms as well as a Full(0) record. 1003 _25._tcp.mail.example.com. IN TLSA 3 1 1 ( 1004 3FE246A848798236DD2AB78D39F0651D 1005 6B6E7CA8E2984012EB0A2E1AC8A87B72 ) 1006 _25._tcp.mail.example.com. IN TLSA 3 1 2 ( 1007 D4F5AF015B46C5057B841C7E7BAB759C 1008 BF029526D29520C5BE6A32C67475439E 1009 54AB3A945D80C743347C9BD4DADC9D8D 1010 57FAB78EAA835362F3CA07CCC19A3214 ) 1011 _25._tcp.mail.example.com. IN TLSA 3 1 0 ( 1012 3059301306072A8648CE3D020106082A 1013 8648CE3D0301070342000471CB1F504F 1014 9E4B33971376C005445DACD33CD79A28 1015 81C3DED1981F18E7AAA76609DD0E4EF2 1016 8265C82703030AD60C5DBA6FB8A9397A 1017 C0FCF06D424C885D484887 ) 1019 In this case the client SHOULD accept a server public key that 1020 matches either the "3 1 0" record or the "3 1 2" record, but SHOULD 1021 NOT accept keys that match only the weaker "3 1 1" record. 1023 10. General DANE Guidelines 1025 These guidelines provide guidance for using or designing protocols 1026 for DANE. 1028 10.1. DANE DNS Record Size Guidelines 1030 Selecting a combination of TLSA parameters to use requires careful 1031 thought. One important consideration to take into account is the 1032 size of the resulting TLSA record after its parameters are selected. 1034 10.1.1. UDP and TCP Considerations 1036 Deployments SHOULD avoid TLSA record sizes that cause UDP 1037 fragmentation. 1039 Although DNS over TCP would provide the ability to more easily 1040 transfer larger DNS records between clients and servers, it is not 1041 universally deployed and is still prohibited by some firewalls. 1042 Clients that request DNS records via UDP typically only use TCP upon 1043 receipt of a truncated response in the DNS response message sent over 1044 UDP. Setting the TC bit alone will be insufficient if the response 1045 containing the TC bit is itself fragmented. 1047 10.1.2. Packet Size Considerations for TLSA Parameters 1049 Server operators SHOULD NOT publish TLSA records using both a TLSA 1050 Selector of Cert(0) and a TLSA Matching Type of Full(0), as even a 1051 single certificate is generally too large to be reliably delivered 1052 via DNS over UDP. Furthermore, two TLSA records containing full 1053 certificates will need to be published simultaneously during a 1054 certificate rollover, as discussed in Section 8.1. 1056 While TLSA records using a TLSA Selector of SPKI(1) and a TLSA 1057 Matching Type of Full(0) (which publish the bare public keys without 1058 the overhead of a containing X.509 certificate) are generally more 1059 compact, these are also best avoided as when significantly larger 1060 than their digests. Rather, servers SHOULD publish digest-based TLSA 1061 Matching Types in their TLSA records. Instead, the complete 1062 corresponding certificate SHOULD be transmitted to the client in-band 1063 during the TLS handshake. The certificate (or raw public key) can be 1064 easily verified using the digest value. 1066 In summary, the use of a TLSA Matching Type of Full(0) is NOT 1067 RECOMMENDED and the use of a digest-based matching type, such as 1068 SHA2-256(1) SHOULD be used. 1070 10.2. Certificate Name Check Conventions 1072 Certificates presented by a TLS server will generally contain a 1073 subjectAltName (SAN) extension or a Common Name (CN) element within 1074 the subject distinguished name (DN). The TLS server's DNS domain 1075 name is normally published within these elements, ideally within the 1076 subjectAltName extension. (The use of the CN field for this purpose 1077 is deprecated.) 1079 When a server hosts multiple domains at the same transport endpoint, 1080 the server's ability to respond with the right certificate chain is 1081 predicated on correct SNI information from the client. DANE clients 1082 MUST send the SNI extension with a HostName value of the base domain 1083 of the TLSA RRset. 1085 Except with TLSA Certificate Usage DANE-EE(3), where name checks are 1086 not applicable (see Section 5.1), DANE clients MUST verify that the 1087 client has reached the correct server by checking that the server 1088 name is listed in the server certificate's SAN or CN. The server 1089 name used for this comparison MUST be the TLSA base domain, however 1090 additional acceptable names may be specified by protocol-specific 1091 DANE standards. For example, with SMTP both the destination domain 1092 name and the MX host name are acceptable names to be found in the 1093 server certificate (see [I-D.ietf-dane-smtp-with-dane]). 1095 It is the responsibility of the service operator, in coordination 1096 with the TLSA Publisher, to ensure that at least one of the TLSA 1097 records published for the service will match the server's certificate 1098 chain (either the default chain or the certificate that was selected 1099 based on the SNI information provided by the client). 1101 Given the DNSSEC validated DNS records below: 1103 example.com. IN MX 0 mail.example.com. 1104 mail.example.com. IN A 192.0.2.1 1105 _25._tcp.mail.example.com. IN TLSA 2 0 1 ( 1106 E8B54E0B4BAA815B06D3462D65FBC7C0 1107 CF556ECCF9F5303EBFBB77D022F834C0 ) 1109 The TLSA base domain is "mail.example.com" and is required to be the 1110 HostName in the client's SNI extension. The server certificate chain 1111 is required to be be signed by a trust anchor with the above 1112 certificate SHA2-256 digest. Finally, one of the DNS names in the 1113 server certificate is required to be be either "mail.example.com" or 1114 "example.com" (this additional name is a concession to compatibility 1115 with prior practice, see [I-D.ietf-dane-smtp-with-dane] for details). 1117 [RFC6125] specifies the the semantics of wildcards in server 1118 certificates for various application protocols. DANE does not change 1119 how wildcards are treated by any given application. 1121 10.3. Design Considerations for Protocols Using DANE 1123 When a TLS client goes to the trouble of authenticating a certificate 1124 chain presented by a TLS server, it will typically not continue to 1125 use that server in the event of authentication failure, or else 1126 authentication serves no purpose. Some clients may, at times, 1127 operate in an "audit" mode, where authentication failure is reported 1128 to the user or in logs as a potential problem, but the connection 1129 proceeds despite the failure. Nevertheless servers publishing TLSA 1130 records MUST be configured to allow correctly configured clients to 1131 successfully authenticate their TLS certificate chains. 1133 A service with DNSSEC-validated TLSA records implicitly promises TLS 1134 support. When all the TLSA records for a service are found 1135 "unusable", due to unsupported parameter combinations or malformed 1136 associated data, DANE clients cannot authenticate the service 1137 certificate chain. When authenticated TLS is mandatory, the client 1138 SHOULD NOT connect to the associated server. 1140 If, on the other hand, the use of TLS is "opportunistic", then the 1141 client SHOULD generally use the server via an unauthenticated TLS 1142 connection, but if TLS encryption cannot be established, the client 1143 MUST NOT use the server. Standards for DANE specific to the 1144 particular application protocol may modify the above requirements, as 1145 appropriate. 1147 11. Note on DNSSEC Security 1149 Clearly the security of the DANE TLSA PKI rests on the security of 1150 the underlying DNSSEC infrastructure. While this document is not a 1151 guide to DNSSEC security, a few comments may be helpful to TLSA 1152 implementers. 1154 With the existing public CA Web PKI, name constraints are rarely 1155 used, and a public root CA can issue certificates for any domain of 1156 its choice. With DNSSEC, under the Registry/Registrar/Registrant 1157 model, the situation is different: only the registrar of record can 1158 update a domain's DS record in the registry parent zone (in some 1159 cases, however, the registry is the sole registrar). With many 1160 Generic Top Level Domains (gTLDs), for which multiple registrars 1161 compete to provide domains in a single registry, it is important to 1162 make sure that rogue registrars cannot easily initiate an 1163 unauthorized domain transfer, and thus take over DNSSEC for the 1164 domain. DNS Operators SHOULD use a registrar lock of their domains 1165 to offer some protection against this possibility. 1167 When the registrar is also the DNS operator for the domain, one needs 1168 to consider whether the registrar will allow orderly migration of the 1169 domain to another registrar or DNS operator in a way that will 1170 maintain DNSSEC integrity. TLSA Publishers SHOULD ensure their 1171 registrar publishes a suitable domain transfer policy. 1173 DNSSEC signed RRsets cannot be securely revoked before they expire. 1174 Operators need to plan accordingly and not generate signatures with 1175 excessively long duration periods. For domains publishing high-value 1176 keys, a signature lifetime of a few days is reasonable, and the zone 1177 can be re-signed daily. For domains with less critical data, a 1178 reasonable signature lifetime is a couple of weeks to a month, and 1179 the zone can be re-signed weekly. Monitoring of the signature 1180 lifetime is important. If the zone is not re-signed in a timely 1181 manner, one risks a major outage and the entire domain will become 1182 bogus. 1184 12. Summary of Updates to RFC6698 1186 o Section 3 updates [RFC6698] to specify a requirement for clients 1187 to support at least TLS 1.0, and to support SNI. 1189 o Section 5.1 updates [RFC6698] to specify peer identity matching 1190 and certificate validity interval based solely on the basis of the 1191 TLSA RRset. It also specifies DANE authentication of raw public 1192 keys [RFC7250] via TLSA records with Certificate Usage DANE-EE(3) 1193 and selector SPKI(1). 1195 o Section 5.2 updates [RFC6698] to require that servers publishing 1196 digest TLSA records with a usage of DANE-TA(2) MUST include the 1197 trust-anchor certificate in their TLS server certificate message. 1198 This extends to the case of "2 1 0" TLSA records which publish a 1199 full public key. 1201 o Section 5.3 and Section 5.4 explain that PKIX-EE(1) and PKIX-TA(0) 1202 are generally NOT RECOMMENDED. This document notes that with 1203 usage PKIX-TA(0) clients may need to processes extended trust 1204 chains beyond the first trusted issuer, when that issuer is not 1205 self-signed. 1207 o Section 7 recommends that DANE application protocols specify that 1208 when possible securely CNAME expanded names be used to derive the 1209 TLSA base domain. 1211 o Section 8 specifies a strategy for managing TLSA records that 1212 interoperates with DANE clients regardless of what subset of the 1213 possible TLSA record types (combinations of TLSA parameters) is 1214 supported by the client. 1216 o Section 9 specifies a digest algorithm agility protocol. 1218 o Section 10.1 recommends against the use of Full(0) TLSA records, 1219 as digest records are generally much more compact. 1221 13. Operational Considerations 1223 The DNS time-to-live (TTL) of TLSA records needs to be chosen with 1224 care. When an unplanned change in the server's certificate chain and 1225 TLSA RRset is required, such as when keys are compromised or lost, 1226 clients that cache stale TLSA records will fail to validate the 1227 certificate chain of the updated server. Publish TLSA RRsets with 1228 TTLs that are short enough to limit unplanned service disruption to 1229 an acceptable duration. 1231 The signature validity period for TLSA records SHOULD NOT be too 1232 long. Signed DNSSEC records can be replayed by an MiTM attacker 1233 provided the signatures have not yet expired. Shorter signature 1234 validity periods allow for faster invalidation of compromised keys. 1235 Zone refresh and expiration times for secondary nameservers often 1236 imply a lower bound on the signature validity period. See 1237 Section 4.4.1 of [RFC6781]. 1239 14. Security Considerations 1241 Application protocols that cannot make use of the existing public CA 1242 Web PKI, may choose to not implement certain TLSA record types 1243 defined in [RFC6698]. If such records are published despite not 1244 being supported by the application protocol, they are treated as 1245 "unusable". When TLS is opportunistic, the client MAY proceed to use 1246 the server with mandatory unauthenticated TLS. This is stronger than 1247 opportunistic TLS without DANE, since in that case the client may 1248 also proceed with a plaintext connection. When TLS is not 1249 opportunistic, the client MUST NOT connect to the server. 1251 Thus, when TLSA records are used with opportunistic protocols where 1252 the PKIX-TA(0( and PKIX-EE(1) do not apply, the recommended protocol 1253 design is for servers to not publish such TLSA records, and for 1254 opportunistic TLS clients to use them to only enforce the use of 1255 (albeit unauthenticated) TLS, but otherwise treat them as unusable. 1256 Of course, when PKIX-TA(0) and PKIX-EE(1) are supported by the 1257 application protocol, clients SHOULD implement these certificate 1258 usages as described in [RFC6698]. 1260 15. IANA Considerations 1262 This specification requires no support from IANA. 1264 16. Acknowledgements 1266 The authors would like to thank Phil Pennock for his comments and 1267 advice on this document. 1269 Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded 1270 me into participating in DANE working group discussions. Thanks to 1271 Paul Hoffman who motivated me to produce this document and provided 1272 feedback on early drafts. Thanks also to Samuel Dukhovni for 1273 editorial assistance. 1275 17. References 1277 17.1. Normative References 1279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1280 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1281 RFC2119, March 1997, 1282 . 1284 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1285 Rose, "DNS Security Introduction and Requirements", RFC 1286 4033, DOI 10.17487/RFC4033, March 2005, 1287 . 1289 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1290 Rose, "Resource Records for the DNS Security Extensions", 1291 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1292 . 1294 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1295 Rose, "Protocol Modifications for the DNS Security 1296 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 1297 . 1299 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1300 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1301 RFC5246, August 2008, 1302 . 1304 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1305 Housley, R., and W. Polk, "Internet X.509 Public Key 1306 Infrastructure Certificate and Certificate Revocation List 1307 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1308 . 1310 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1311 Extensions: Extension Definitions", RFC 6066, DOI 1312 10.17487/RFC6066, January 2011, 1313 . 1315 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1316 Verification of Domain-Based Application Service Identity 1317 within Internet Public Key Infrastructure Using X.509 1318 (PKIX) Certificates in the Context of Transport Layer 1319 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1320 2011, . 1322 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1323 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1324 January 2012, . 1326 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1327 of Named Entities (DANE) Transport Layer Security (TLS) 1328 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1329 2012, . 1331 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 1332 Conversations about DNS-Based Authentication of Named 1333 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 1334 2014, . 1336 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1337 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1338 Transport Layer Security (TLS) and Datagram Transport 1339 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1340 June 2014, . 1342 17.2. Informative References 1344 [I-D.ietf-dane-smtp-with-dane] 1345 Dukhovni, V. and W. Hardaker, "SMTP security via 1346 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-19 1347 (work in progress), May 2015. 1349 [I-D.ietf-dane-srv] 1350 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 1351 Based Authentication of Named Entities (DANE) TLSA Records 1352 with SRV Records", draft-ietf-dane-srv-14 (work in 1353 progress), April 2015. 1355 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 1356 Operational Practices, Version 2", RFC 6781, DOI 10.17487/ 1357 RFC6781, December 2012, 1358 . 1360 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1361 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 1362 . 1364 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1365 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1366 December 2014, . 1368 Authors' Addresses 1370 Viktor Dukhovni 1371 Unaffiliated 1373 Email: ietf-dane@dukhovni.org 1375 Wes Hardaker 1376 Parsons 1377 P.O. Box 382 1378 Davis, CA 95617 1379 US 1381 Email: ietf@hardakers.net