idnits 2.17.1 draft-ietf-dane-ops-11.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In this case the client SHOULD accept a server public key that matches either the "3 1 0" record or the "3 1 2" record, but SHOULD not accept keys that match only the weaker "3 1 1" record. -- The document date (May 29, 2015) is 3254 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) == Outdated reference: A later version (-19) exists of draft-ietf-dane-smtp-with-dane-18 -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 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: November 30, 2015 May 29, 2015 8 Updates to and Operational Guidance for the DANE Protocol 9 draft-ietf-dane-ops-11 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 November 30, 2015. 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 . . . . . . . . . 7 59 4.1. Opportunistic Security and PKIX usages . . . . . . . . . 7 60 4.2. Interaction with Certificate Transparency . . . . . . . . 8 61 4.3. Transitioning between PKIX-TA/EE and 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 . . . . . . . . . . . . 19 73 8.4. TLSA Publisher Requirements Summary . . . . . . . . . . . 20 74 9. Digest Algorithm Agility . . . . . . . . . . . . . . . . . . 20 75 10. General DANE Guidelines . . . . . . . . . . . . . . . . . . . 21 76 10.1. DANE DNS Record Size Guidelines . . . . . . . . . . . . 22 77 10.2. Certificate Name Check Conventions . . . . . . . . . . . 22 78 10.3. Design Considerations for Protocols Using DANE . . . . . 24 79 11. Note on DNSSEC Security . . . . . . . . . . . . . . . . . . . 24 80 12. Summary of Updates to RFC6698 . . . . . . . . . . . . . . . . 25 81 13. Operational Considerations . . . . . . . . . . . . . . . . . 26 82 14. Security Considerations . . . . . . . . . . . . . . . . . . . 26 83 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 84 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 85 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 86 17.1. Normative References . . . . . . . . . . . . . . . . . . 27 87 17.2. Informative References . . . . . . . . . . . . . . . . . 28 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 90 1. Introduction 92 The DANE TLSA specification ([RFC6698]) introduces the DNS "TLSA" 93 resource record type. TLSA records associate a certificate or a 94 public key of an end-entity or a trusted issuing authority with the 95 corresponding TLS transport endpoint. DNSSEC validated DANE TLSA 96 records can be used to augment or replace the use of trusted public 97 Certification Authorities (CAs). 99 [RFC6698] defines three TLSA record fields with respectively 4, 2 and 100 3 currently specified values. These yield 24 distinct combinations 101 of TLSA record types. This document recommends a smaller set of 102 best-practice combinations of these fields to simplify protocol 103 design, implementation and deployment. 105 Implementation complexity also arises from the fact that the TLS 106 transport endpoint is often specified indirectly via Service Records 107 (SRV), Mail Exchange (MX) records, CNAME records or other mechanisms 108 that map an abstract service domain to a concrete server domain. 109 With service indirection there are multiple potential places for 110 clients to find the relevant TLSA records. Service indirection is 111 often used to implement "virtual hosting", where a single Service 112 Provider transport endpoint simultaneously supports multiple hosted 113 domain names. With services that employ TLS, such hosting 114 arrangements may require the Service Provider to deploy multiple 115 pairs of private keys and certificates. The TLS clients, then, 116 signal the desired domain to the TLSA server via the Server Name 117 Indication (SNI) extension ([RFC6066], section 3). This document 118 provides operational guidelines intended to maximize interoperability 119 between DANE TLS clients and servers. 121 In the context of this document, channel security is assumed to be 122 provided by TLS or DTLS. The Transport Layer Security (TLS) 123 [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347] 124 protocols provide secured TCP and UDP communication, respectively, 125 over IP. By convention, "TLS" will be used throughout this document 126 and, unless otherwise specified, the text applies equally well to the 127 DTLS over UDP protocol. Used without authentication, TLS provides 128 protection only against eavesdropping through its use of encryption. 129 With authentication, TLS also provides integrity protection and 130 authentication, which protects the transport against man-in-the- 131 middle (MITM) attacks. 133 Other related documents that build on [RFC6698] are 134 [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]. 136 In Section 12 we summarize the normative updates this document makes 137 to [RFC6698]. 139 1.1. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in 144 [RFC2119]. 146 The following terms are used throughout this document: 148 Service Provider: A company or organization that offers to host a 149 service on behalf of the owner of a Customer Domain. The original 150 domain name associated with the service often remains under the 151 control of the customer. Connecting applications may be directed 152 to the Service Provider via a redirection resource record. 153 Example redirection records include MX, SRV, and CNAME. The 154 Service Provider frequently provides services for many customers 155 and must carefully manage any TLS credentials offered to 156 connecting applications to ensure name matching is handled easily 157 by the applications. 159 Customer Domain: As described above, a TLS client may be interacting 160 with a service that is hosted by a third party. We will refer to 161 the domain name used to locate the service (prior to any 162 redirection) as the "Customer Domain". 164 TLSA Publisher: The entity responsible for publishing a TLSA record 165 within a DNS zone. This zone will be assumed DNSSEC-signed and 166 validatable to a trust anchor, unless otherwise specified. If the 167 Customer Domain is not outsourcing their DNS service, the TLSA 168 Publisher will be the customer themselves. Otherwise, the TLSA 169 Publisher may be the operator of the outsourced DNS service. 171 public key: The term "public key" is short-hand for the 172 subjectPublicKeyInfo component of a PKIX [RFC5280] certificate. 174 SNI: The "Server Name Indication" (SNI) TLS protocol extension 175 allows a TLS client to request a connection to a particular 176 service name of a TLS server ([RFC6066], section 3). Without this 177 TLS extension, a TLS server has no choice but to offer a PKIX 178 certificate with a default list of server names, making it 179 difficult to host multiple Customer Domains at the same IP- 180 addressed based TLS service endpoint (i.e., "secure virtual 181 hosting"). 183 TLSA parameters: In [RFC6698] the TLSA record is defined to consist 184 of four fields. The first three of these are numeric parameters 185 that specify the meaning of the data in fourth and final field. 186 To avoid language contortions when we need to distinguish between 187 the first three fields that together define a TLSA record "type" 188 and the fourth that provides a data value of that type, we will 189 call the first three fields "TLSA parameters", or sometimes just 190 "parameters" when obvious from context. 192 2. DANE TLSA Record Overview 194 DANE TLSA [RFC6698] specifies a protocol for publishing TLS server 195 certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035]. 196 The DANE TLSA specification defines multiple TLSA RR types via 197 combinations of numeric values of the first three fields of the TLSA 198 record (i.e. the "TLSA parameters"). The numeric values of these 199 parameters were later given symbolic names in [RFC7218]. These 200 parameters are: 202 The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies 4 203 values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3). There 204 is an additional private-use value: PrivCert(255), which, given 205 its private scope, shall not be considered further in this 206 document. All other values are reserved for use by future 207 specifications. 209 The selector field: Section 2.1.2 of [RFC6698] specifies 2 values: 210 Cert(0), SPKI(1). There is an additional private-use value: 211 PrivSel(255). All other values are reserved for use by future 212 specifications. 214 The matching type field: Section 2.1.3 of [RFC6698] specifies 3 215 values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional 216 private-use value: PrivMatch(255). All other values are reserved 217 for use by future specifications. 219 We may think of TLSA Certificate Usage values 0 through 3 as a 220 combination of two one-bit flags. The low-bit chooses between trust 221 anchor (TA) and end entity (EE) certificates. The high bit chooses 222 between PKIX (public PKI issued) and DANE (domain-issued) trust 223 anchors: 225 o When the low bit is set (PKIX-EE(1) and DANE-EE(3)) the TLSA 226 record matches an EE certificate (also commonly referred to as a 227 leaf or server certificate.) 229 o When the low bit is not set (PKIX-TA(0) and DANE-TA(2)) the TLSA 230 record matches a trust anchor (a Certification Authority) that 231 issued one of the certificates in the server certificate chain. 233 o When the high bit is set (DANE-TA(2) and DANE-EE(3)), the server 234 certificate chain is domain-issued and may be verified without 235 reference to any pre-configured Certification Authority trust 236 anchor. Trust is based solely on the content of the TLSA records 237 obtained via DNSSEC. 239 o When the high bit is not set (PKIX-TA(0) and PKIX-EE(1)), the TLSA 240 record publishes a server policy stating that its certificate 241 chain must pass PKIX validation [RFC5280] and the DANE TLSA record 242 is used to signal an additional requirement that the PKIX 243 validated server certificate chain also contains the referenced CA 244 or EE certificate. 246 The selector field specifies whether the TLSA RR matches the whole 247 certificate (Cert(0)) or just its subjectPublicKeyInfo (SPKI(1)). 248 The subjectPublicKeyInfo is an ASN.1 DER encoding of the 249 certificate's algorithm id, any parameters and the public key data. 251 The matching type field specifies how the TLSA RR Certificate 252 Association Data field is to be compared with the certificate or 253 public key. A value of Full(0) means an exact match: the full DER 254 encoding of the certificate or public key is given in the TLSA RR. A 255 value of SHA2-256(1) means that the association data matches the 256 SHA2-256 digest of the certificate or public key, and likewise 257 SHA2-512(2) means a SHA2-512 digest is used. Of the two digest 258 algorithms, for now only SHA2-256(1) is mandatory to implement. 259 Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT 260 exclusively publish SHA2-512(2) digests. The digest algorithm 261 agility protocol defined in Section 9 SHOULD be used by clients to 262 decide how to process TLSA RRsets that employ multiple digest 263 algorithms. Server operators MUST publish TLSA RRsets that are 264 compatible with digest algorithm agility. 266 2.1. Example TLSA record 268 In the example TLSA record below: 270 _25._tcp.mail.example.com. IN TLSA 2 0 1 ( 271 E8B54E0B4BAA815B06D3462D65FBC7C0 272 CF556ECCF9F5303EBFBB77D022F834C0 ) 274 The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and 275 the matching type is SHA2-256(1). The last field is the Certificate 276 Association Data Field, which in this case contains the SHA2-256 277 digest of the server certificate. 279 3. DANE TLS Requirements 281 [RFC6698] does not discuss what versions of TLS are required when 282 using DANE records. This document specifies that TLS clients that 283 support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support 284 TLS 1.2. TLS clients and servers using DANE SHOULD support the 285 "Server Name Indication" (SNI) extension of TLS. 287 4. DANE Certificate-Usage Selection Guidelines 289 As mentioned in Section 2, the TLSA certificate usage field takes one 290 of four possible values. With PKIX-TA(0) and PKIX-EE(1), the 291 validation of peer certificate chains requires additional pre- 292 configured CA trust anchors that are mutually trusted by the 293 operators of the TLS server and client. With DANE-TA(2) and DANE- 294 EE(3), no pre-configured CA trust anchors are required and the 295 published DANE TLSA records are sufficient to verify the peer's 296 certificate chain. 298 Protocol designers should carefully consider which set of DANE 299 certificate usages to support. Simultaneous support for all four 300 usages is NOT RECOMMENDED for DANE clients. Protocol designers 301 should either use the PKIX-TA(0) and PKIX-EE(1) certificate usages, 302 or use the DANE-TA(2) and DANE-EE(3) usages. If all four usages are 303 deployed together, an attacker capable of compromising the integrity 304 of DNSSEC needs only to replace server's TLSA RRset with one that 305 lists suitable DANE-EE(3) or DANE-TA(2) records, effectively 306 bypassing the PKIX required checks. In other words, when all four 307 usages are supported, PKIX-TA(2) and PKIX-EE(1) offer only illusory 308 incremental security. 310 This document recommends that clients should generally support just 311 the DANE-TA(2) and DANE-EE(3) certificate usages. With DANE-TA(2) 312 and DANE-EE(3) clients don't need to track a large changing list of 313 X.509 trust-anchors. Supporting PKIX-TA(0) or PKIX-EE(1) decreases 314 the operational reliability of DANE-based authentication. 316 The DNSSEC TLSA records for servers MAY include both sets of usages 317 if the server needs to support a mixture of clients; some supporting 318 one pair of usages and some the other. 320 4.1. Opportunistic Security and PKIX usages 322 When the client's protocol design is based on Opportunistic Security 323 (OS, [RFC7435]), and the use of authentication is based on the 324 presence of server TLSA records, it is especially important to avoid 325 the PKIX-EE(1) and PKIX-TA(0) certificate usages. Since the presence 326 and data integrity of TLSA records relies on DNSSEC, PKIX-TA(0) and 327 PKIX-EE(1) TLSA records do not provide additional security. With the 328 PKIX-TA(0) and PKIX-EE(1) usages offering no more security, but being 329 more prone to failure, they are a poor fit for opportunistic security 330 and SHOULD NOT be used in that context. 332 4.2. Interaction with Certificate Transparency 334 Certificate Transparency (CT) [RFC6962] defines an approach to 335 mitigate the risk of rogue or compromised public CAs issuing 336 unauthorized certificates. This section clarifies the interaction of 337 CT and DANE. 339 When a server is authenticated via a DANE TLSA RR with TLSA 340 Certificate Usage DANE-EE(3), the domain owner has directly specified 341 the certificate associated with the given service without reference 342 to any public certification authority. Therefore, when a TLS client 343 authenticates the TLS server via a TLSA record with usage DANE-EE(3), 344 CT checks SHOULD NOT be performed. Publication of the server 345 certificate or public key (digest) in a TLSA record in a DNSSEC 346 signed zone by the domain owner assures the TLS client that the 347 certificate is not an unauthorized certificate issued by a rogue CA 348 without the domain owner's consent. 350 When a server is authenticated via a DANE TLSA record with TLSA usage 351 DANE-TA(2) and the server certificate does not chain to a known 352 public root CA, CT cannot apply (CT logs only accept chains that 353 start with a known, public root). Since TLSA Certificate Usage DANE- 354 TA(2) is generally intended to support non-public trust anchors, TLS 355 clients SHOULD NOT perform CT checks with usage DANE-TA(2). 357 4.3. Transitioning between PKIX-TA/EE and DANE-TA/EE 359 The choice of preferred certificate usages may need to change as a 360 protocol evolves. When transitioning between PKIX-TA/PKIX-EE and 361 DANE-TA/DANE-EE, clients begin to enable support for the new 362 certificate usage values. If the new preferred certificate usages 363 are PKIX-TA/EE this requires installing and managing the appropriate 364 set of CA trust anchors. During this time servers will publish both 365 types of TLSA records. At some later time when the vast majority of 366 servers have published the new preferred TLSA records, clients can 367 stop supporting the legacy certificate usages. Similarly, servers 368 can stop publishing legacy TLSA records once the vast majority of 369 clients support the new certificate usages. 371 5. Certificate-Usage Specific DANE Updates and Guidelines 373 The four Certificate Usage values from the TLSA record, DANE-EE(3), 374 DANE-TA(2), PKIX-EE(1) and PKIX-TA(0), are discussed below. 376 5.1. Certificate Usage DANE-EE(3) 378 In this section the meaning of DANE-EE(3) is updated from [RFC6698] 379 to specify that peer identity matching and that validity period 380 enforcement is based solely on the TLSA RRset properties. We also 381 extend [RFC6698] to cover the use of DANE authentication of raw 382 public keys [RFC7250] via TLSA records with Certificate Usage DANE- 383 EE(3) and selector SPKI(1). 385 Authentication via certificate usage DANE-EE(3) TLSA records involves 386 simply checking that the server's leaf certificate matches the TLSA 387 record. In particular, the binding of the server public key to its 388 name is based entirely on the TLSA record association. The server 389 MUST be considered authenticated even if none of the names in the 390 certificate match the client's reference identity for the server. 392 Similarly, with DANE-EE(3), the expiration date of the server 393 certificate MUST be ignored. The validity period of the TLSA record 394 key binding is determined by the validity period of the TLSA record 395 DNSSEC signatures. 397 With DANE-EE(3) servers that know all the connecting clients are 398 making use of DANE, they need not employ SNI (i.e., they may ignore 399 the client's SNI message) even when the server is known under 400 multiple domain names that would otherwise require separate 401 certificates. It is instead sufficient for the TLSA RRsets for all 402 the domain names in question to match the server's primary 403 certificate. For application protocols where the server name is 404 obtained indirectly via SRV, MX or similar records, it is simplest to 405 publish a single hostname as the target server name for all the 406 hosted domains. 408 In organizations where it is practical to make coordinated changes in 409 DNS TLSA records before server key rotation, it is generally best to 410 publish end-entity DANE-EE(3) certificate associations in preference 411 to other choices of certificate usage. DANE-EE(3) TLSA records 412 support multiple server names without SNI, don't suddenly stop 413 working when leaf or intermediate certificates expire, and don't fail 414 when a server operator neglects to include all the required issuer 415 certificates in the server certificate chain. 417 TLSA records published for DANE servers SHOULD, as a best practice, 418 be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE 419 implementations are required to support SHA2-256, this record type 420 works for all clients and need not change across certificate renewals 421 with the same key. This TLSA record type easily supports hosting 422 arrangements with a single certificate matching all hosted domains. 423 It is also the easiest to implement correctly in the client. 425 Another advantage of "DANE-EE(3) SPKI(1)" (with any suitable matching 426 type) TLSA records is that they are compatible with the raw public 427 key TLS extension specified in [RFC7250]. DANE clients that support 428 this extension can use the TLSA record to authenticate servers that 429 negotiate the use of raw public keys in place of X.509 certificate 430 chains. Provided the server adheres to the requirements of 431 Section 8, the fact that raw public keys are not compatible with any 432 other TLSA record types will not get in the way of successful 433 authentication. Clients that employ DANE to authenticate the peer 434 server SHOULD NOT negotiate the use of raw public keys unless the 435 server's TLSA RRset includes compatible TLSA records. 437 While it is, in principle, also possible to authenticate raw public 438 keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the 439 public key from the certificate in DNS, this is in conflict with the 440 indicated selector and requires extra logic on clients that not all 441 implementations are expected to provide. Servers SHOULD NOT rely on 442 "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication 443 data for raw public keys. 445 5.2. Certificate Usage DANE-TA(2) 447 This section updates [RFC6698] by specifying a new operational 448 requirement for servers publishing TLSA records with a usage of DANE- 449 TA(2): such servers MUST include the trust-anchor certificate in 450 their TLS server certificate message. 452 Some domains may prefer to avoid the operational complexity of 453 publishing unique TLSA RRs for each TLS service. If the domain 454 employs a common issuing Certification Authority to create 455 certificates for multiple TLS services, it may be simpler to publish 456 the issuing authority as a trust anchor (TA) for the certificate 457 chains of all relevant services. The TLSA query domain (TLSA base 458 domain with port and protocol prefix labels) for each service issued 459 by the same TA may then be set to a CNAME alias that points to a 460 common TLSA RRset that matches the TA. For example: 462 www1.example.com. IN A 192.0.2.1 463 www2.example.com. IN A 192.0.2.2 464 _443._tcp.www1.example.com. IN CNAME tlsa201._dane.example.com. 465 _443._tcp.www2.example.com. IN CNAME tlsa201._dane.example.com. 466 tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14... 468 With usage DANE-TA(2) the server certificates will need to have names 469 that match one of the client's reference identifiers (see [RFC6125]). 470 The server SHOULD employ SNI to select the appropriate certificate to 471 present to the client. 473 5.2.1. Recommended record combinations 475 TLSA records with matching type Full(0) are NOT RECOMMENDED. While 476 these potentially obviate the need to transmit the TA certificate in 477 the TLS server certificate message, client implementations may not be 478 able to augment the server certificate chain with the data obtained 479 from DNS, especially when the TLSA record supplies a bare key 480 (selector SPKI(1)). Since the server will need to transmit the TA 481 certificate in any case, server operators SHOULD publish TLSA records 482 with a matching type other than Full(0) and avoid potential DNS 483 interoperability issues with large TLSA records containing full 484 certificates or keys (see Section 10.1.1). 486 TLSA Publishers employing DANE-TA(2) records SHOULD publish records 487 with a selector of Cert(0). Such TLSA records are associated with 488 the whole trust anchor certificate, not just with the trust anchor 489 public key. In particular, the client SHOULD then apply any relevant 490 constraints from the trust anchor certificate, such as, for example, 491 path length constraints. 493 While a selector of SPKI(1) may also be employed, the resulting TLSA 494 record will not specify the full trust anchor certificate content, 495 and elements of the trust anchor certificate other than the public 496 key become mutable. This may, for example, enable a subsidiary CA to 497 issue a chain that violates the trust anchor's path length or name 498 constraints. 500 5.2.2. Trust anchor digests and server certificate chain 502 With DANE-TA(2), a complication arises when the TA certificate is 503 omitted from the server's certificate chain, perhaps on the basis of 504 Section 7.4.2 of [RFC5246]: 506 The sender's certificate MUST come first in the list. Each 507 following certificate MUST directly certify the one preceding 508 it. Because certificate validation requires that root keys be 509 distributed independently, the self-signed certificate that 510 specifies the root certification authority MAY be omitted from 511 the chain, under the assumption that the remote end must 512 already possess it in order to validate it in any case. 514 With TLSA Certificate Usage DANE-TA(2), there is no expectation that 515 the client is pre-configured with the trust anchor certificate. In 516 fact, client implementations are free to ignore all locally 517 configured trust anchors when processing usage DANE-TA(2) TLSA 518 records and may rely exclusively on the certificates provided in the 519 server's certificate chain. But, with a digest in the TLSA record, 520 the TLSA record contains neither the full trust anchor certificate 521 nor the full public key. If the TLS server's certificate chain does 522 not contain the trust anchor certificate, DANE clients will be unable 523 to authenticate the server. 525 TLSA Publishers that publish TLSA Certificate Usage DANE-TA(2) 526 associations with a selector of SPKI(1) or using a digest-based 527 matching type (not Full(0)) MUST ensure that the corresponding server 528 is configured to also include the trust anchor certificate in its TLS 529 handshake certificate chain, even if that certificate is a self- 530 signed root CA and would have been optional in the context of the 531 existing public CA PKI. 533 5.2.3. Trust anchor public keys 535 TLSA records with TLSA Certificate Usage DANE-TA(2), selector SPKI(1) 536 and a matching type of Full(0) will publish the full public key of a 537 trust anchor via DNS. In section 6.1.1 of [RFC5280] the definition 538 of a trust anchor consists of the following four parts: 540 1. the trusted issuer name, 542 2. the trusted public key algorithm, 544 3. the trusted public key, and 546 4. optionally, the trusted public key parameters associated with the 547 public key. 549 Items 2-4 are precisely the contents of the subjectPublicKeyInfo 550 published in the TLSA record. The issuer name is not included in the 551 subjectPublicKeyInfo. 553 With TLSA Certificate Usage DANE-TA(2), the client may not have the 554 associated trust anchor certificate, and cannot generally verify 555 whether a particular certificate chain is "issued by" the trust 556 anchor described in the TLSA record. 558 When the server certificate chain includes a CA certificate whose 559 public key matches the TLSA record, the client can match that CA as 560 the intended issuer. Otherwise, the client can only check that the 561 topmost certificate in the server's chain is "signed by" the trust 562 anchor's public key in the TLSA record. Such a check may be 563 difficult to implement, and cannot be expected to be supported by all 564 clients. 566 Thus, servers should not rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA 567 records to be sufficient to authenticate chains issued by the 568 associated public key in the absence of a corresponding certificate 569 in the server's TLS certificate message. Servers SHOULD include the 570 TA certificate in their certificate chain. 572 If none of the server's certificate chain elements match a public key 573 specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1) 574 Full(0)" TLSA record is available, clients are encouraged to check 575 whether the topmost certificate in the chain is signed by the 576 provided public key and has not expired, and in that case consider 577 the server authenticated, provided the rest of the chain passes 578 validation including leaf certificate name checks. 580 5.3. Certificate Usage PKIX-EE(1) 582 This Certificate Usage is similar to DANE-EE(3), but in addition PKIX 583 verification is required. Therefore, name checks, certificate 584 expiration, etc., apply as they would without DANE. 586 5.4. Certificate Usage PKIX-TA(0) 588 This section updates [RFC6698] by specifying new client 589 implementation requirements. Clients that trust intermediate 590 certificates MUST be prepared to construct longer PKIX chains than 591 would be required for PKIX alone. 593 TLSA Certificate Usage PKIX-TA(0) allows a domain to publish 594 constraints on the set of PKIX certification authorities trusted to 595 issue certificates for its TLS servers. This TLSA record matches 596 PKIX-verified trust chains which contain an issuer certificate (root 597 or intermediate) that matches its association data field (typically a 598 certificate or digest). 600 PKIX-TA(0) also requires more complex coordination between the 601 Customer Domain and the Service Provider in hosting arrangements. 602 Thus, this certificate usage is NOT RECOMMENDED when the Service 603 Provider is not also the TLSA Publisher. 605 TLSA Publishers who publish TLSA records for a particular public root 606 CA, will expect that clients will only accept chains anchored at that 607 root. It is possible, however, that the client's trusted certificate 608 store includes some intermediate CAs, either with or without the 609 corresponding root CA. When a client constructs a trust chain 610 leading from a trusted intermediate CA to the server leaf 611 certificate, such a "truncated" chain might not contain the trusted 612 root published in the server's TLSA record. 614 If the omitted root is also trusted, the client may erroneously 615 reject the server chain if it fails to determine that the shorter 616 chain it constructed extends to a longer trusted chain that matches 617 the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record, 618 a client SHOULD NOT always stop extending the chain when the first 619 locally trusted certificate is found. If no TLSA records have 620 matched any of the elements of the chain, and the trusted certificate 621 found is not self-issued, the client MUST attempt to build a longer 622 chain in the hope that a certificate closer to the root may in fact 623 match the server's TLSA record. 625 6. Service Provider and TLSA Publisher Synchronization 627 Complications arise when the TLSA Publisher is not the same entity as 628 the Service Provider. In this situation, the TLSA Publisher and the 629 Service Provider must cooperate to ensure that TLSA records published 630 by the TLSA Publisher don't fall out of sync with the server 631 certificate used by the Service Provider. 633 Whenever possible, the TLSA Publisher and the Service Provider should 634 be the same entity. Otherwise, changes in the service certificate 635 chain must be carefully coordinated between the parties involved. 636 Such coordination is difficult and service outages will result when 637 coordination fails. 639 Having the master TLSA record in the Service Provider's zone avoids 640 the complexity of bilateral coordination of server certificate 641 configuration and TLSA record management. Even when the TLSA RRset 642 must be published in the Customer Domain's DNS zone (perhaps the 643 client application does not "chase" CNAMEs to the TLSA base domain), 644 it is possible to employ CNAME records to delegate the content of the 645 TLSA RRset to a domain operated by the Service Provider. Certificate 646 name checks generally constrain the applicability of TLSA CNAMEs 647 across organizational boundaries to Certificate Usages DANE-EE(3) and 648 DANE-TA(2): 650 Certificate Usage DANE-EE(3): In this case the Service Provider can 651 publish a single TLSA RRset that matches the server certificate or 652 public key digest. The same RRset works for all Customer Domains 653 because name checks do not apply with DANE-EE(3) TLSA records (see 654 Section 5.1). A Customer Domain can create a CNAME record 655 pointing to the TLSA RRset published by the Service Provider. 657 Certificate Usage DANE-TA(2): When the Service Provider operates a 658 private certification authority, the Service Provider is free to 659 issue a certificate bearing any customer's domain name. Without 660 DANE, such a certificate would not pass trust verification, but 661 with DANE, the customer's TLSA RRset that is aliased to the 662 provider's TLSA RRset can delegate authority to the provider's CA 663 for the corresponding service. The Service Provider can generate 664 appropriate certificates for each customer and use the SNI 665 information provided by clients to select the right certificate 666 chain to present to each client. 668 Below are example DNS records (assumed "secure" and shown without the 669 associated DNSSEC information, such as record signatures) that 670 illustrate both of of the above models in the case of an HTTPS 671 service whose clients all support DANE TLS. These examples work even 672 with clients that don't "chase" CNAMEs when constructing the TLSA 673 base domain (see Section 7 below). 675 ; The hosted web service is redirected via a CNAME alias. 676 ; The associated TLSA RRset is also redirected via a CNAME alias. 677 ; 678 ; A single certificate at the provider works for all Customer 679 ; Domains due to the use of the DANE-EE(3) Certificate Usage. 680 ; 681 www1.example.com. IN CNAME w1.example.net. 682 _443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net. 683 _443._tcp.w1.example.net. IN TLSA 3 1 1 ( 684 8A9A70596E869BED72C69D97A8895DFA 685 D86F300A343FECEFF19E89C27C896BC9 ) 687 ; 688 ; A CA at the provider can also issue certificates for each Customer 689 ; Domain, and use the DANE-TA(2) Certificate Usage type to 690 ; indicate a trust anchor. 691 ; 692 www2.example.com. IN CNAME w2.example.net. 693 _443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net. 694 _443._tcp.w2.example.net. IN TLSA 2 0 1 ( 695 C164B2C3F36D068D42A6138E446152F5 696 68615F28C69BD96A73E354CAC88ED00C ) 698 With protocols that support explicit transport redirection via DNS MX 699 records, SRV records, or other similar records, the TLSA base domain 700 is based on the redirected transport end-point, rather than the 701 origin domain. With SMTP, for example, when an email service is 702 hosted by a Service Provider, the Customer Domain's MX hostnames will 703 point at the Service Provider's SMTP hosts. When the Customer 704 Domain's DNS zone is signed, the MX hostnames can be securely used as 705 the base domains for TLSA records that are published and managed by 706 the Service Provider. For example (without the required DNSSEC 707 information, such as record signatures): 709 ; Hosted SMTP service 710 ; 711 example.com. IN MX 0 mx1.example.net. 712 example.com. IN MX 0 mx2.example.net. 713 _25._tcp.mx1.example.net. IN TLSA 3 1 1 ( 714 8A9A70596E869BED72C69D97A8895DFA 715 D86F300A343FECEFF19E89C27C896BC9 ) 716 _25._tcp.mx2.example.net. IN TLSA 3 1 1 ( 717 C164B2C3F36D068D42A6138E446152F5 718 68615F28C69BD96A73E354CAC88ED00C ) 720 If redirection to the Service Provider's domain (via MX or SRV 721 records or any similar mechanism) is not possible, and aliasing of 722 the TLSA record is not an option, then more complex coordination 723 between the Customer Domain and Service Provider will be required. 724 Either the Customer Domain periodically provides private keys and a 725 corresponding certificate chain to the Provider (after making 726 appropriate changes in its TLSA records), or the Service Provider 727 periodically generates the keys and certificates and must wait for 728 matching TLSA records to be published by its Customer Domains before 729 deploying newly generated keys and certificate chains. In Section 7 730 below, we describe an approach that employs CNAME "chasing" to avoid 731 the difficulties of coordinating key management across organization 732 boundaries. 734 For further information about combining DANE and SRV, please see 735 [I-D.ietf-dane-srv]. 737 7. TLSA Base Domain and CNAMEs 739 When the application protocol does not support service location 740 indirection via MX, SRV or similar DNS records, the service may be 741 redirected via a CNAME. A CNAME is a more blunt instrument for this 742 purpose, since unlike an MX or SRV record, it remaps the entire 743 origin domain to the target domain for all protocols. 745 The complexity of coordinating key management is largely eliminated 746 when DANE TLSA records are found in the Service Provider's domain, as 747 discussed in Section 6. Therefore, DANE TLS clients connecting to a 748 server whose domain name is a CNAME alias SHOULD follow the CNAME 749 hop-by-hop to its ultimate target host (noting at each step whether 750 the CNAME is DNSSEC-validated). If at each stage of CNAME expansion 751 the DNSSEC validation status is "secure", the final target name 752 SHOULD be the preferred base domain for TLSA lookups. 754 Implementations failing to find a TLSA record using a base name of 755 the final target of a CNAME expansion SHOULD issue a TLSA query using 756 the original destination name. That is, the preferred TLSA base 757 domain should be derived from the fully expanded name, and failing 758 that should be the initial domain name. 760 When the TLSA base domain is the result of "secure" CNAME expansion, 761 the resulting domain name MUST be used as the HostName in SNI, and 762 MUST be the primary reference identifier for peer certificate 763 matching with certificate usages other than DANE-EE(3). 765 Protocol-specific TLSA specifications may provide additional guidance 766 or restrictions when following CNAME expansions. 768 Though CNAMEs are illegal on the right hand side of most indirection 769 records, such as MX and SRV records, they are supported by some 770 implementations. For example, if the MX or SRV host is a CNAME 771 alias, some implementations may "chase" the CNAME. If they do, they 772 SHOULD use the target hostname as the preferred TLSA base domain as 773 described above (and if the TLSA records are found there, use the 774 CNAME expanded domain also in SNI and certificate name checks). 776 8. TLSA Publisher Requirements 778 This section updates [RFC6698] by specifying a requirement on the 779 TLSA Publisher to ensure that each combination of Certificate Usage, 780 selector and matching type in the server's TLSA RRset MUST include at 781 least one record that matches the server's current certificate chain. 782 TLSA records that match recently retired or yet to be deployed 783 certificate chains will be present during key rollover. Such past or 784 future records must never be the only records published for any given 785 combination of usage, selector and matching type. We describe a TLSA 786 record update algorithm that ensures this requirement is met. 788 While a server is to be considered authenticated when its certificate 789 chain is matched by any of the published TLSA records, not all 790 clients support all combinations of TLSA record parameters. Some 791 clients may not support some digest algorithms, others may either not 792 support, or may exclusively support, the PKIX Certificate Usages. 793 Some clients may prefer to negotiate [RFC7250] raw public keys, which 794 are only compatible with TLSA records whose Certificate Usage is 795 DANE-EE(3) with selector SPKI(1). 797 A consequence of the above uncertainty as to which TLSA parameters 798 are supported by any given client is that servers need to ensure that 799 each and every parameter combination that appears in the TLSA RRset 800 is, on its own, sufficient to match the server's current certificate 801 chain. In particular, when deploying new keys or new parameter 802 combinations some care is required to not generate parameter 803 combinations that only match past or future certificate chains (or 804 raw public keys). The rest of this section explains how to update 805 the TLSA RRset in a manner that ensures the above requirement is met. 807 8.1. Key rollover with fixed TLSA Parameters 809 The simplest case is key rollover while retaining the same set of 810 published parameter combinations. In this case, TLSA records 811 matching the existing server certificate chain (or raw public keys) 812 are first augmented with corresponding records matching the future 813 keys, at least two TTLs or longer before the the new chain is 814 deployed. This allows the obsolete RRset to age out of client caches 815 before the new chain is used in TLS handshakes. Once sufficient time 816 has elapsed and all clients performing DNS lookups are retrieving the 817 updated TLSA records, the server administrator may deploy the new 818 certificate chain, verify that it works, and then remove any obsolete 819 records matching the no longer active chain: 821 ; Initial TLSA RRset 822 ; 823 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 825 ; Transitional TLSA RRset published at least 2*TTL seconds 826 ; before the actual key change 827 ; 828 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 829 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 831 ; Final TLSA RRset after the key change 832 ; 833 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 835 The next case to consider is adding or switching to a new combination 836 of TLSA parameters. In this case publish the new parameter 837 combinations for the server's existing certificate chain first, and 838 only then deploy new keys if desired: 840 ; Initial TLSA RRset 841 ; 842 _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46... 844 ; New TLSA RRset, same key re-published as DANE-EE(3) 845 ; 846 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 848 8.2. Switching to DANE-TA from DANE-EE 850 This section explains how to migrate to a new certificate chain and 851 TLSA records with usage DANE-TA(2) from a self-signed server 852 certificate. Here the process is to add DANE-TA(2) TLSA records 853 matching the future chain, but retain the existing TLSA parameters 854 for the legacy self-signed certificate. It is not possible to 855 publish DANE-TA(2) TLSA records for for the legacy self-signed 856 certificate. After deploying the new chain, drop the legacy TLSA 857 record. 859 ; Initial TLSA RRset 860 ; 861 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 863 ; Transitional (mixed) TLSA RRset, published at least 2*TTL before 864 ; the actual key change. 865 ; 866 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 867 _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d... 869 ; Final TLSA RRset after the key change. 870 ; 871 _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d... 873 8.3. Switching to New TLSA Parameters 875 When employing a new digest algorithm in the TLSA RRset, for 876 compatibility with digest agility specified in Section 9 below, 877 administrators should publish the new digest algorithm with each 878 combinations of Certificate Usage and selector for each associated 879 key or chain used with any other digest algorithm. When removing an 880 algorithm, remove it entirely. Each digest algorithm employed should 881 match the same set of chains (or raw public keys). 883 ; Initial TLSA RRset with DANE-EE SHA2-256 associations for two keys. 884 ; 885 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 886 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 888 ; New TLSA RRset also with SHA2-512 associations for each key 889 ; 890 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 891 _443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc... 892 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 893 _443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714... 895 8.4. TLSA Publisher Requirements Summary 897 In summary, server operators updating TLSA records should make one 898 change at a time. The individual safe changes are: 900 o Pre-publish new certificate associations that employ the same TLSA 901 parameters (usage, selector and matching type) as existing TLSA 902 records, but match certificate chains that will be deployed in the 903 near future. Wait for stale TLSA RRsets to expire from DNS caches 904 before configuring servers to use the new certificate chain. 906 o Remove TLSA records matching no longer deployed certificate 907 chains. 909 o Extend the TLSA RRset with a new combination of parameters (usage, 910 selector and matching type) that is used to generate matching 911 associations for all certificate chains that are published with 912 some other parameter combination. 914 The above steps are intended to ensure that at all times and for each 915 combination of usage, selector and matching type at least one TLSA 916 record corresponds to the server's current certificate chain. No 917 combination of Certificate Usage, selector and matching type in a 918 server's TLSA RRset should ever match only some combination of future 919 or past certificate chains. As a result, no matter what combinations 920 of usage, selector and matching type may be supported by a given 921 client, they will be sufficient to authenticate the server. 923 9. Digest Algorithm Agility 925 While [RFC6698] specifies multiple digest algorithms, it does not 926 specify a protocol by which the client and TLSA record publisher can 927 agree on the strongest shared algorithm. Such a protocol would allow 928 the client and server to avoid exposure to deprecated weaker 929 algorithms that are published for compatibility with less capable 930 clients, but which SHOULD be avoided when possible. We specify such 931 a protocol below. 933 This section defines a protocol for avoiding deprecated digest 934 algorithms when these are published in a peer's TLSA RRset alongside 935 stronger digest algorithms. Note that this protocol never avoids RRs 936 with DANE matching type Full(0), as these do not employ a digest 937 algorithm that might some day be weakened by cryptanalysis. 939 Client implementations SHOULD implement a default order of digest 940 algorithms by strength. This order SHOULD be configurable by the MTA 941 administrator. If possible, a configurable mapping from numeric DANE 942 TLSA matching types to underlying digest algorithms provided by the 943 cryptographic library SHOULD be implemented to allow new matching 944 types to be used with software that predates their introduction. 945 Configurable ordering of digest algorithms SHOULD be extensible to 946 any new digest algorithms. 948 To make digest algorithm agility possible, all published DANE TLSA 949 RRsets MUST conform to the requirements of Section 8. Clients SHOULD 950 use digest algorithm agility when processing the peer's DANE TLSA 951 records. Algorithm agility is to be applied after first discarding 952 any unusable or malformed records (unsupported digest algorithm, or 953 incorrect digest length). For each usage and selector, the client 954 SHOULD process only any usable records with a matching type of 955 Full(0) and the usable records whose digest algorithm is considered 956 by the client to be the strongest among usable records with the given 957 usage and selector. 959 Example: a client implements digest agility and prefers SHA2-512(2) 960 over SHA2-256(1), while the server publishes an RRset that employs 961 both digest algorithms as well as a Full(0) record. 963 _25._tcp.mail.example.com. IN TLSA 3 1 1 ( 964 3FE246A848798236DD2AB78D39F0651D 965 6B6E7CA8E2984012EB0A2E1AC8A87B72 ) 966 _25._tcp.mail.example.com. IN TLSA 3 1 2 ( 967 D4F5AF015B46C5057B841C7E7BAB759C 968 BF029526D29520C5BE6A32C67475439E 969 54AB3A945D80C743347C9BD4DADC9D8D 970 57FAB78EAA835362F3CA07CCC19A3214 ) 971 _25._tcp.mail.example.com. IN TLSA 3 1 0 ( 972 3059301306072A8648CE3D020106082A 973 8648CE3D0301070342000471CB1F504F 974 9E4B33971376C005445DACD33CD79A28 975 81C3DED1981F18E7AAA76609DD0E4EF2 976 8265C82703030AD60C5DBA6FB8A9397A 977 C0FCF06D424C885D484887 ) 979 In this case the client SHOULD accept a server public key that 980 matches either the "3 1 0" record or the "3 1 2" record, but SHOULD 981 not accept keys that match only the weaker "3 1 1" record. 983 10. General DANE Guidelines 985 These guidelines provide guidance for using or designing protocols 986 for DANE. 988 10.1. DANE DNS Record Size Guidelines 990 Selecting a combination of TLSA parameters to use requires careful 991 thought. One important consideration to take into account is the 992 size of the resulting TLSA record after its parameters are selected. 994 10.1.1. UDP and TCP Considerations 996 Deployments SHOULD avoid TLSA record sizes that cause UDP 997 fragmentation. 999 Although DNS over TCP would provide the ability to more easily 1000 transfer larger DNS records between clients and servers, it is not 1001 universally deployed and is still prohibited by some firewalls. 1002 Clients that request DNS records via UDP typically only use TCP upon 1003 receipt of a truncated response in the DNS response message sent over 1004 UDP. Setting the TC bit alone will be insufficient if the response 1005 containing the TC bit is itself fragmented. 1007 10.1.2. Packet Size Considerations for TLSA Parameters 1009 Server operators SHOULD NOT publish TLSA records using both a TLSA 1010 Selector of Cert(0) and a TLSA Matching Type of Full(0), as even a 1011 single certificate is generally too large to be reliably delivered 1012 via DNS over UDP. Furthermore, two TLSA records containing full 1013 certificates will need to be published simultaneously during a 1014 certificate rollover, as discussed in Section 8.1. 1016 While TLSA records using a TLSA Selector of SPKI(1) and a TLSA 1017 Matching Type of Full(0) (which publish the bare public keys without 1018 the overhead of a containing X.509 certificate) are generally more 1019 compact, these too should be used with caution as they are still 1020 larger than necessary. Rather, servers SHOULD publish digest-based 1021 TLSA Matching Types in their TLSA records. The complete 1022 corresponding certificate should, instead, be transmitted to the 1023 client in-band during the TLS handshake, which can be easily verified 1024 using the digest value. 1026 In summary, the use of a TLSA Matching Type of Full(0) is NOT 1027 RECOMMENDED and the use of a digest-based matching type, such as 1028 SHA2-256(1) SHOULD be used. 1030 10.2. Certificate Name Check Conventions 1032 Certificates presented by a TLS server will generally contain a 1033 subjectAltName (SAN) extension or a Common Name (CN) element within 1034 the subject distinguished name (DN). The TLS server's DNS domain 1035 name is normally published within these elements, ideally within the 1036 subjectAltName extension. (The use of the CN field for this purpose 1037 is deprecated.) 1039 When a server hosts multiple domains at the same transport endpoint, 1040 the server's ability to respond with the right certificate chain is 1041 predicated on correct SNI information from the client. DANE clients 1042 MUST send the SNI extension with a HostName value of the base domain 1043 of the TLSA RRset. 1045 Except with TLSA Certificate Usage DANE-EE(3), where name checks are 1046 not applicable (see Section 5.1), DANE clients MUST verify that the 1047 client has reached the correct server by checking that the server 1048 name is listed in the server certificate's SAN or CN. The server 1049 name used for this comparison SHOULD be the base domain of the TLSA 1050 RRset. Additional acceptable names may be specified by protocol- 1051 specific DANE standards. For example, with SMTP both the destination 1052 domain name and the MX host name are acceptable names to be found in 1053 the server certificate (see [I-D.ietf-dane-smtp-with-dane]). 1055 It is the responsibility of the service operator, in coordination 1056 with the TLSA Publisher, to ensure that at least one of the TLSA 1057 records published for the service will match the server's certificate 1058 chain (either the default chain or the certificate that was selected 1059 based on the SNI information provided by the client). 1061 Given the DNSSEC validated DNS records below: 1063 example.com. IN MX 0 mail.example.com. 1064 mail.example.com. IN A 192.0.2.1 1065 _25._tcp.mail.example.com. IN TLSA 2 0 1 ( 1066 E8B54E0B4BAA815B06D3462D65FBC7C0 1067 CF556ECCF9F5303EBFBB77D022F834C0 ) 1069 The TLSA base domain is "mail.example.com" and is required to be the 1070 HostName in the client's SNI extension. The server certificate chain 1071 is required to be be signed by a trust anchor with the above 1072 certificate SHA2-256 digest. Finally, one of the DNS names in the 1073 server certificate is required to be be either "mail.example.com" or 1074 "example.com" (this additional name is a concession to compatibility 1075 with prior practice, see [I-D.ietf-dane-smtp-with-dane] for details). 1077 The semantics of wildcards in server certificates are left to 1078 individual application protocol specifications. 1080 10.3. Design Considerations for Protocols Using DANE 1082 When a TLS client goes to the trouble of authenticating a certificate 1083 chain presented by a TLS server, it will typically not continue to 1084 use that server in the event of authentication failure, or else 1085 authentication serves no purpose. Some clients may, at times, 1086 operate in an "audit" mode, where authentication failure is reported 1087 to the user or in logs as a potential problem, but the connection 1088 proceeds despite the failure. Nevertheless servers publishing TLSA 1089 records MUST be configured to allow correctly configured clients to 1090 successfully authenticate their TLS certificate chains. 1092 A service with DNSSEC-validated TLSA records implicitly promises TLS 1093 support. When all the TLSA records for a service are found 1094 "unusable", due to unsupported parameter combinations or malformed 1095 associated data, DANE clients cannot authenticate the service 1096 certificate chain. When authenticated TLS is dictated by the 1097 application, the client SHOULD NOT connect to the associated server. 1098 If, on the other hand, the use of TLS is "opportunistic", then the 1099 client SHOULD generally use the server via an unauthenticated TLS 1100 connection, but if TLS encryption cannot be established, the client 1101 MUST NOT use the server. Standards for DANE specific to the 1102 particular application protocol may modify the above requirements, as 1103 appropriate, to specify whether the connection should be established 1104 anyway without relying on TLS security, with only encryption but not 1105 authentication, or whether to refuse to connect entirely. 1106 Application protocols need to specify when to prioritize security 1107 over the ability to connect under adverse conditions. 1109 11. Note on DNSSEC Security 1111 Clearly the security of the DANE TLSA PKI rests on the security of 1112 the underlying DNSSEC infrastructure. While this document is not a 1113 guide to DNSSEC security, a few comments may be helpful to TLSA 1114 implementers. 1116 With the existing public CA PKI, name constraints are rarely used, 1117 and a public root CA can issue certificates for any domain of its 1118 choice. With DNSSEC, under the Registry/Registrar/Registrant model, 1119 the situation is different: only the registrar of record can update a 1120 domain's DS record in the registry parent zone (in some cases, 1121 however, the registry is the sole registrar). With many gTLDs, for 1122 which multiple registrars compete to provide domains in a single 1123 registry, it is important to make sure that rogue registrars cannot 1124 easily initiate an unauthorized domain transfer, and thus take over 1125 DNSSEC for the domain. DNS Operators SHOULD use a registrar lock of 1126 their domains to offer some protection against this possibility. 1128 When the registrar is also the DNS operator for the domain, one needs 1129 to consider whether the registrar will allow orderly migration of the 1130 domain to another registrar or DNS operator in a way that will 1131 maintain DNSSEC integrity. TLSA Publishers SHOULD ensure their 1132 registrar publishes a suitable domain transfer policy. 1134 DNSSEC signed RRsets cannot be securely revoked before they expire. 1135 Operators should plan accordingly and not generate signatures with 1136 excessively long duration periods. For domains publishing high-value 1137 keys, a signature lifetime of a few days is reasonable, and the zone 1138 should be resigned daily. For domains with less critical data, a 1139 reasonable signature lifetime is a couple of weeks to a month, and 1140 the zone should be resigned weekly. Monitoring of the signature 1141 lifetime is important. If the zone is not resigned in a timely 1142 manner, one risks a major outage and the entire domain will become 1143 bogus. 1145 12. Summary of Updates to RFC6698 1147 o In Section 3 we update [RFC6698] to specify a requirement for 1148 clients to support at least TLS 1.0, and to support SNI. 1150 o In Section 5.1 we update [RFC6698] to specify peer identity 1151 matching and certificate validity interval based solely on the 1152 basis of the TLSA RRset. We also specify DANE authentication of 1153 raw public keys [RFC7250] via TLSA records with Certificate Usage 1154 DANE-EE(3) and selector SPKI(1). 1156 o In Section 5.2 we update [RFC6698] to require that servers 1157 publishing digest TLSA records with a usage of DANE-TA(2) MUST 1158 include the trust-anchor certificate in their TLS server 1159 certificate message. This extends to the case of "2 1 0" TLSA 1160 records which publish a full public key. 1162 o In Section 5.3 and Section 5.4, we explain that PKIX-EE(1) and 1163 PKIX-TA(0) are generally NOT RECOMMENDED. With usage PKIX-TA(0) 1164 we note that clients may need to processes extended trust chains 1165 beyond the first trusted issuer, when that issuer is not self- 1166 signed. 1168 o In Section 7, we recommend that DANE application protocols specify 1169 that when possible securely CNAME expanded names be used to derive 1170 the TLSA base domain. 1172 o In Section 8, we specify a strategy for managing TLSA records that 1173 interoperates with DANE clients regardless of what subset of the 1174 possible TLSA record types (combinations of TLSA parameters) is 1175 supported by the client. 1177 o In Section 9, we specify a digest algorithm agility protocol. 1179 o In Section 10.1 we recommend against the use of Full(0) TLSA 1180 records, as digest records are generally much more compact. 1182 13. Operational Considerations 1184 The DNS time-to-live (TTL) of TLSA records needs to be chosen with 1185 care. When an unplanned change in the server's certificate chain and 1186 TLSA RRset is required, such as when keys are compromised or lost, 1187 clients that cache stale TLSA records will fail to validate the 1188 certificate chain of the updated server. TLSA RRsets should have 1189 TTLs that are short enough to limit unplanned service disruption to 1190 an acceptable duration. 1192 The signature validity period for TLSA records should also not be too 1193 long. Signed DNSSEC records can be replayed by an MiTM attacker 1194 provided the signatures have not yet expired. Shorter signature 1195 validity periods allow for faster invalidation of compromised keys. 1196 Zone refresh and expiration times for secondary nameservers often 1197 imply a lower bound on the signature validity period. See 1198 Section 4.4.1 of [RFC6781]. 1200 14. Security Considerations 1202 Application protocols that cannot make use of the existing public CA 1203 PKI (so called non-PKIX protocols), may choose not to implement 1204 certain PKIX-dependent TLSA record types defined in [RFC6698]. If 1205 such records are published despite not being supported by the 1206 application protocol, they are treated as "unusable". When TLS is 1207 opportunistic, the client may proceed to use the server with 1208 mandatory unauthenticated TLS. This is stronger than opportunistic 1209 TLS without DANE, since in that case the client may also proceed with 1210 a plaintext connection. When TLS is not opportunistic, the client 1211 MUST NOT connect to the server. 1213 Therefore, when TLSA records are used with protocols where PKIX does 1214 not apply, the recommended policy is for servers to not publish PKIX- 1215 dependent TLSA records, and for opportunistic TLS clients to use them 1216 to enforce the use of (albeit unauthenticated) TLS, but otherwise 1217 treat them as unusable. Of course, when PKIX validation is supported 1218 by the application protocol, clients SHOULD perform PKIX validation 1219 per [RFC6698]. 1221 15. IANA Considerations 1223 This specification requires no support from IANA. 1225 16. Acknowledgements 1227 The authors would like to thank Phil Pennock for his comments and 1228 advice on this document. 1230 Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded 1231 me into participating in DANE working group discussions. Thanks to 1232 Paul Hoffman who motivated me to produce this document and provided 1233 feedback on early drafts. Thanks also to Samuel Dukhovni for 1234 editorial assistance. 1236 17. References 1238 17.1. Normative References 1240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1241 Requirement Levels", BCP 14, RFC 2119, March 1997. 1243 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1244 Rose, "DNS Security Introduction and Requirements", RFC 1245 4033, March 2005. 1247 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1248 Rose, "Resource Records for the DNS Security Extensions", 1249 RFC 4034, March 2005. 1251 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1252 Rose, "Protocol Modifications for the DNS Security 1253 Extensions", RFC 4035, March 2005. 1255 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1256 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1258 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1259 Housley, R., and W. Polk, "Internet X.509 Public Key 1260 Infrastructure Certificate and Certificate Revocation List 1261 (CRL) Profile", RFC 5280, May 2008. 1263 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1264 Extension Definitions", RFC 6066, January 2011. 1266 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1267 Verification of Domain-Based Application Service Identity 1268 within Internet Public Key Infrastructure Using X.509 1269 (PKIX) Certificates in the Context of Transport Layer 1270 Security (TLS)", RFC 6125, March 2011. 1272 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1273 Security Version 1.2", RFC 6347, January 2012. 1275 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1276 of Named Entities (DANE) Transport Layer Security (TLS) 1277 Protocol: TLSA", RFC 6698, August 2012. 1279 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 1280 Conversations about DNS-Based Authentication of Named 1281 Entities (DANE)", RFC 7218, April 2014. 1283 17.2. Informative References 1285 [I-D.ietf-dane-smtp-with-dane] 1286 Dukhovni, V. and W. Hardaker, "SMTP security via 1287 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-18 1288 (work in progress), May 2015. 1290 [I-D.ietf-dane-srv] 1291 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 1292 Based Authentication of Named Entities (DANE) TLSA Records 1293 with SRV Records", draft-ietf-dane-srv-14 (work in 1294 progress), April 2015. 1296 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 1297 Operational Practices, Version 2", RFC 6781, December 1298 2012. 1300 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1301 Transparency", RFC 6962, June 2013. 1303 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 1304 T. Kivinen, "Using Raw Public Keys in Transport Layer 1305 Security (TLS) and Datagram Transport Layer Security 1306 (DTLS)", RFC 7250, June 2014. 1308 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1309 Most of the Time", RFC 7435, December 2014. 1311 Authors' Addresses 1313 Viktor Dukhovni 1314 Unaffiliated 1316 Email: ietf-dane@dukhovni.org 1318 Wes Hardaker 1319 Parsons 1320 P.O. Box 382 1321 Davis, CA 95617 1322 US 1324 Email: ietf@hardakers.net