idnits 2.17.1 draft-ietf-dane-ops-06.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 abstract seems to contain references ([RFC6698]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 17, 2014) is 3539 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 (-06) exists of draft-dukhovni-opportunistic-security-03 == Outdated reference: A later version (-19) exists of draft-ietf-dane-smtp-with-dane-11 == Outdated reference: A later version (-14) exists of draft-ietf-dane-srv-07 -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DANE V. Dukhovni 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track W. Hardaker 5 Expires: February 18, 2015 Parsons 6 August 17, 2014 8 Updates to and Operational Guidance for the DANE Protocol 9 draft-ietf-dane-ops-06 11 Abstract 13 This memo clarifies and updates the DANE TLSA protocol based on 14 implementation experience since the publication of the original DANE 15 specification in [RFC6698]. It also contains guidance for DANE 16 implementers and operators. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 18, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. DANE TLSA Record Overview . . . . . . . . . . . . . . . . . . 4 55 2.1. Example TLSA record . . . . . . . . . . . . . . . . . . . 6 56 3. DANE TLS Requirements . . . . . . . . . . . . . . . . . . . . 6 57 4. Certificate-Usage-Specific DANE Updates and Guidelines . . . 7 58 4.1. Certificate Usage DANE-EE(3) . . . . . . . . . . . . . . 7 59 4.2. Certificate Usage DANE-TA(2) . . . . . . . . . . . . . . 8 60 4.3. Certificate Usage PKIX-EE(1) . . . . . . . . . . . . . . 11 61 4.4. Certificate Usage PKIX-TA(0) . . . . . . . . . . . . . . 12 62 4.5. Opportunistic Security and PKIX usages . . . . . . . . . 12 63 5. Service Provider and TLSA Publisher Synchronization . . . . . 13 64 6. TLSA Base Domain and CNAMEs . . . . . . . . . . . . . . . . . 15 65 7. TLSA Publisher Requirements . . . . . . . . . . . . . . . . . 16 66 7.1. Key rollover with fixed TLSA Parameters . . . . . . . . . 17 67 7.2. Switching to DANE-TA from DANE-EE . . . . . . . . . . . . 18 68 7.3. Switching to New TLSA Parameters . . . . . . . . . . . . 18 69 7.4. TLSA Publisher Requirements Summary . . . . . . . . . . . 19 70 8. Digest Algorithm Agility . . . . . . . . . . . . . . . . . . 19 71 9. General DANE Guidelines . . . . . . . . . . . . . . . . . . . 20 72 9.1. DANE DNS Record Size Guidelines . . . . . . . . . . . . . 21 73 9.2. Certificate Name Check Conventions . . . . . . . . . . . 21 74 9.3. Design Considerations for Protocols Using DANE . . . . . 23 75 10. Interaction with Certificate Transparency . . . . . . . . . . 23 76 11. Note on DNSSEC Security . . . . . . . . . . . . . . . . . . . 24 77 12. Summary of Updates to RFC6698 . . . . . . . . . . . . . . . . 25 78 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 79 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 80 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 81 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 16.1. Normative References . . . . . . . . . . . . . . . . . . 27 83 16.2. Informative References . . . . . . . . . . . . . . . . . 28 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 86 1. Introduction 88 [RFC6698] specifies a new DNS resource record "TLSA" that associates 89 a public certificate or public key of a trusted leaf or issuing 90 authority with the corresponding TLS transport endpoint. These DANE 91 TLSA records, when validated by DNSSEC, can be used to augment or 92 replace the trust model of the existing public Certification 93 Authority (CA) Public Key Infrastructure (PKI). 95 [RFC6698] defines three TLSA record fields with respectively 4, 2 and 96 3 currently specified values. These yield 24 distinct combinations 97 of TLSA record types. This many options have lead to implementation 98 and operational complexity. This memo will recommend best-practice 99 choices to help simplify implementation and deployment given these 100 plethora of choices. 102 Implementation complexity also arises from the fact that the TLS 103 transport endpoint is often specified indirectly via Service Records 104 (SRV), Mail Exchange (MX) records, CNAME records or other mechanisms 105 that map an abstract service domain to a concrete server domain. 106 With service indirection there are multiple potential places for 107 clients to find the relevant TLSA records. Service indirection is 108 often used to implement "virtual hosting", where a single Service 109 Provider transport endpoint simultaneously supports multiple hosted 110 domain names. With services that employ TLS, such hosting 111 arrangements may require the Service Provider to deploy multiple 112 pairs of private keys and certificates with TLS clients signaling the 113 desired domain via the Server Name Indication (SNI) extension 114 ([RFC6066], section 3). This memo provides operational guidelines 115 intended to maximize interoperability between DANE TLS clients and 116 servers. 118 In the context of this memo, channel security is assumed to be 119 provided by TLS or DTLS. The Transport Layer Security (TLS) 120 [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347] 121 protocols provide secured TCP and UDP communication over IP. By 122 convention, "TLS" will be used throughout this document and, unless 123 otherwise specified, the text applies equally well to the DTLS 124 protocol. Used without authentication, TLS provides protection only 125 against eavesdropping through its use of encryption. With 126 authentication, TLS also provides integrity protection and 127 authentication, which protect the transport against man-in-the-middle 128 (MITM) attacks. 130 Other related documents that build on [RFC6698] are 131 [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]. In 132 Section 12 we summarize the updates this document makes to [RFC6698]. 134 1.1. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in 139 [RFC2119]. 141 The following terms are used throughout this document: 143 Service Provider: A company or organization that offers to host a 144 service on behalf of a Customer Domain. The original domain name 145 associated with the service often remains under the control of the 146 customer. Connecting applications may be directed to the Service 147 Provider via a redirection resource record. Example redirection 148 records include MX, SRV, and CNAME. The Service Provider 149 frequently provides services for many customers and must carefully 150 manage any TLS credentials offered to connecting applications to 151 ensure name matching is handled easily by the applications. 153 Customer Domain: As described above, a client may be interacting 154 with a service that is hosted by a third party. We will refer to 155 the domain name used to locate the service prior to any 156 redirection, as the "Customer Domain". 158 TLSA Publisher: The entity responsible for publishing a TLSA record 159 within a DNS zone. This zone will be assumed DNSSEC-signed and 160 validatable to a trust anchor, unless otherwise specified. If the 161 Customer Domain is not outsourcing their DNS service, the TLSA 162 Publisher will be the customer themselves. Otherwise, the TLSA 163 Publisher is sometimes the operator of the outsourced DNS service. 165 public key: The term "public key" is short-hand for the 166 subjectPublicKeyInfo component of a PKIX [RFC5280] certificate. 168 SNI: The "Server Name Indication" (SNI) TLS protocol extension 169 allows a TLS client to request a connection to a particular 170 service name of a TLS server ([RFC6066], section 3). Without this 171 TLS extension, a TLS server has no choice but to offer a PKIX 172 certificate with a default list of server names, making it 173 difficult to host multiple Customer Domains at the same IP- 174 addressed based TLS service endpoint (i.e., "secure virtual 175 hosting"). 177 TLSA parameters: In [RFC6698] the TLSA record is defined to consist 178 of four fields. The first three of these are numeric parameters 179 that specify the meaning of the data in fourth and final field. 180 To avoid language contortions when we need to distinguish between 181 the first three fields that together define a TLSA record "type" 182 and the fourth that provides a data value of that type, we will 183 call the first three fields "TLSA parameters", or sometimes just 184 "parameters" when obvious from context. 186 2. DANE TLSA Record Overview 187 DANE TLSA [RFC6698] specifies a protocol for publishing TLS server 188 certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035]. 189 The DANE TLSA specification defines multiple TLSA RR types via 190 combinations of numeric values of the first three fields of the TLSA 191 record (i.e. the "TLSA parameters"). The numeric values of these 192 parameters were later given symbolic names in [RFC7218]. These 193 parameters are: 195 The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies 4 196 values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3). There 197 is an additional private-use value: PrivCert(255). All other 198 values are reserved for use by future specifications. 200 The selector field: Section 2.1.2 of [RFC6698] specifies 2 values: 201 Cert(0), SPKI(1). There is an additional private-use value: 202 PrivSel(255). All other values are reserved for use by future 203 specifications. 205 The matching type field: Section 2.1.3 of [RFC6698] specifies 3 206 values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional 207 private-use value: PrivMatch(255). All other values are reserved 208 for use by future specifications. 210 We may think of TLSA Certificate Usage values 0 through 3 as a 211 combination of two one-bit flags. The low-bit chooses between trust 212 anchor (TA) and end entity (EE) certificates. The high bit chooses 213 between PKIX, or public PKI issued, and DANE, or domain-issued trust 214 anchors: 216 o When the low bit is set (PKIX-EE(1) and DANE-EE(3)) the TLSA 217 record matches an EE certificate (also commonly referred to as a 218 leaf or server certificate.) 220 o When the low bit is not set (PKIX-TA(0) and DANE-TA(2)) the TLSA 221 record matches a trust anchor (a Certification Authority) that 222 issued one of the certificates in the server certificate chain. 224 o When the high bit is set (DANE-TA(2) and DANE-EE(3)), the server 225 certificate chain is domain-issued and may be verified without 226 reference to any pre-existing public certification authority PKI. 227 Trust is entirely placed on the content of the TLSA records 228 obtained via DNSSEC. 230 o When the high bit is not set (PKIX-TA(0) and PKIX-EE(1)), the TLSA 231 record publishes a server policy stating that its certificate 232 chain must pass PKIX validation [RFC5280] and the DANE TLSA record 233 is used to signal an additional requirement that the PKIX 234 validated server certificate chain also contains the referenced CA 235 or EE certificate. 237 The selector field specifies whether the TLSA RR matches the whole 238 certificate (Cert(0)) or just its subjectPublicKeyInfo (SPKI(1)). 239 The subjectPublicKeyInfo is an ASN.1 DER encoding of the 240 certificate's algorithm id, any parameters and the public key data. 242 The matching type field specifies how the TLSA RR Certificate 243 Association Data field is to be compared with the certificate or 244 public key. A value of Full(0) means an exact match: the full DER 245 encoding of the certificate or public key is given in the TLSA RR. A 246 value of SHA2-256(1) means that the association data matches the 247 SHA2-256 digest of the certificate or public key, and likewise 248 SHA2-512(2) means a SHA2-512 digest is used. Of the two digest 249 algorithms, for now only SHA2-256(1) is mandatory to implement. 250 Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT 251 exclusively publish SHA2-512(2) digests. The digest algorithm 252 agility protocol defined in Section 8 SHOULD be used by clients to 253 decide how to process TLSA RRsets that employ multiple digest 254 algorithms. Server operators MUST publish TLSA RRsets that are 255 compatible with digest algorithm agility. 257 2.1. Example TLSA record 259 In the example TLSA record below: 261 _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 ( 262 E8B54E0B4BAA815B06D3462D65FBC7C0 263 CF556ECCF9F5303EBFBB77D022F834C0 ) 265 The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and 266 the matching type is SHA2-256(1). The last field is the Certificate 267 Association Data Field, which in this case contains the SHA2-256 268 digest of the server certificate. 270 3. DANE TLS Requirements 272 [RFC6698] does not discuss what versions of TLS are required when 273 using DANE records. This document specifies that TLS clients that 274 support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support 275 TLS 1.2. TLS clients and servers using DANE SHOULD support the 276 "Server Name Indication" (SNI) extension of TLS. 278 4. Certificate-Usage-Specific DANE Updates and Guidelines 280 The four Certificate Usage values from the TLSA record, DANE-EE(3), 281 DANE-TA(2), PKIX-EE(1) and PKIX-TA(0), are discussed below. 283 4.1. Certificate Usage DANE-EE(3) 285 In this section the meaning of DANE-EE(3) is updated from [RFC6698] 286 to specify that peer identity matching and that validity interval 287 compliance is based solely on the TLSA RRset properties. We also 288 extend [RFC6698] to cover the use of DANE authentication of raw 289 public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with 290 Certificate Usage DANE-EE(3) and selector SPKI(1). 292 Authentication via certificate usage DANE-EE(3) TLSA records involves 293 simply checking that the server's leaf certificate matches the TLSA 294 record. In particular, the binding of the server public key to its 295 name is based entirely on the TLSA record association. The server 296 MUST be considered authenticated even if none of the names in the 297 certificate match the client's reference identity for the server. 299 Similarly, with DANE-EE(3), the expiration date of the server 300 certificate MUST be ignored. The validity period of the TLSA record 301 key binding is determined by the validity interval of the TLSA record 302 DNSSEC signatures. 304 With DANE-EE(3) servers that know all the connecting clients are 305 making use of DANE, they need not employ SNI (i.e., the may ignore 306 the client's SNI message) even when the server is known under 307 multiple domain names that would otherwise require separate 308 certificates. It is instead sufficient for the TLSA RRsets for all 309 the domain names in question to match the server's primary 310 certificate. For application protocols where the server name is 311 obtained indirectly via SRV, MX or similar records, it is simplest to 312 publish a single hostname as the target server name for all the 313 hosted domains. 315 In organizations where it is practical to make coordinated changes in 316 DNS TLSA records before server key rotation, it is generally best to 317 publish end-entity DANE-EE(3) certificate associations in preference 318 to other choices of certificate usage. DANE-EE(3) TLSA records 319 support multiple server names without SNI, don't suddenly stop 320 working when leaf or intermediate certificates expire, and don't fail 321 when a server operator neglects to include all the required issuer 322 certificates in the server certificate chain. 324 TLSA records published for DANE servers SHOULD, as a best practice, 325 be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE 326 implementations are required to support SHA2-256, this record type 327 works for all clients and need not change across certificate renewals 328 with the same key. This TLSA record type easily supports hosting 329 arrangements with a single certificate matching all hosted domains. 330 It is also the easiest to implement correctly in the client. 332 Another advantage of "DANE-EE(3) SPKI(1)" (with any suitable matching 333 type) TLSA records is that they are compatible with the raw public 334 key TLS extension specified in [I-D.ietf-tls-oob-pubkey]. DANE 335 clients that support this extension can use the TLSA record to 336 authenticate servers that negotiate the use of raw public keys in 337 place of X.509 certificate chains. Provided the server adheres to 338 the requirements of Section 7, the fact that raw public keys are not 339 compatible with any other TLSA record types will not get in the way 340 of successful authentication. Clients that employ DANE to 341 authenticate the peer server SHOULD NOT negotiate the use of raw 342 public keys unless the server's TLSA RRset includes compatible TLSA 343 records. 345 While it is, in principle, also possible to authenticate raw public 346 keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the 347 public key from the certificate in DNS, this is in conflict with the 348 indicated selector and requires extra logic on clients that not all 349 implementations are expected to provide. Servers SHOULD NOT rely on 350 "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication 351 data for raw public keys. 353 4.2. Certificate Usage DANE-TA(2) 355 This section updates [RFC6698] by specifying a new operational 356 requirement for servers publishing TLSA records with a usage of DANE- 357 TA(2): such servers MUST include the trust-anchor certificate in 358 their TLS server certificate message. 360 Some domains may prefer to avoid the operational complexity of 361 publishing unique TLSA RRs for each TLS service. If the domain 362 employs a common issuing Certification Authority to create 363 certificates for multiple TLS services, it may be simpler to publish 364 the issuing authority as a trust anchor (TA) for the certificate 365 chains of all relevant services. The TLSA query domain (TLSA base 366 domain with port and protocol prefix labels) for each service issued 367 by the same TA may then be set to a CNAME alias that points to a 368 common TLSA RRset that matches the TA. For example: 370 www1.example.com. IN A 192.0.2.1 371 www2.example.com. IN A 192.0.2.2 372 _443._tcp.www1.example.com. IN CNAME tlsa201._dane.example.com. 373 _443._tcp.www2.example.com. IN CNAME tlsa201._dane.example.com. 374 tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14... 376 With usage DANE-TA(2) the server certificates will need to have names 377 that match one of the client's reference identifiers (see [RFC6125]). 378 The server SHOULD employ SNI to select the appropriate certificate to 379 present to the client. 381 4.2.1. Recommended record combinations 383 TLSA records with selector Full(0) are NOT RECOMMENDED. While these 384 potentially obviate the need to transmit the TA certificate in the 385 TLS server certificate message, client implementations may not be 386 able to augment the server certificate chain with the data obtained 387 from DNS, especially when the TLSA record supplies a bare key 388 (selector SPKI(1)). Since the server will need to transmit the TA 389 certificate in any case, server operators SHOULD publish TLSA records 390 with a selector other than Full(0) and avoid potential DNS 391 interoperability issues with large TLSA records containing full 392 certificates or keys (see Section 9.1.1). 394 TLSA Publishers employing DANE-TA(2) records SHOULD publish records 395 with a selector of Cert(0). Such TLSA records are associated with 396 the whole trust anchor certificate, not just with the trust anchor 397 public key. In particular, the client SHOULD then apply any relevant 398 constraints from the trust anchor certificate, such as, for example, 399 path length constraints. 401 While a selector of SPKI(1) may also be employed, the resulting TLSA 402 record will not specify the full trust anchor certificate content, 403 and elements of the trust anchor certificate other than the public 404 key become mutable. This may, for example, enable a subsidiary CA to 405 issue a chain that violates the trust anchor's path length or name 406 constraints. 408 4.2.2. Trust anchor digests and server certificate chain 410 With DANE-TA(2) (these TLSA records are expected to match the digest 411 of a TA certificate or public key), a complication arises when the TA 412 certificate is omitted from the server's certificate chain, perhaps 413 on the basis of Section 7.4.2 of [RFC5246]: 415 The sender's certificate MUST come first in the list. Each 416 following certificate MUST directly certify the one preceding 417 it. Because certificate validation requires that root keys be 418 distributed independently, the self-signed certificate that 419 specifies the root certification authority MAY be omitted from 420 the chain, under the assumption that the remote end must 421 already possess it in order to validate it in any case. 423 With TLSA Certificate Usage DANE-TA(2), there is no expectation that 424 the client is pre-configured with the trust anchor certificate. In 425 fact, client implementations are free to ignore all locally 426 configured trust anchors when processing usage DANE-TA(2) TLSA 427 records and may rely exclusively on the certificates provided in the 428 server's certificate chain. But, with a digest in the TLSA record, 429 the TLSA record contains neither the full trust anchor certificate 430 nor the full public key. If the TLS server's certificate chain does 431 not contain the trust anchor certificate, DANE clients will be unable 432 to authenticate the server. 434 TLSA Publishers that publish TLSA Certificate Usage DANE-TA(2) 435 associations with a selector of SPKI(1) or using a digest-based 436 matching type (not Full(0)) MUST ensure that the corresponding server 437 is configured to also include the trust anchor certificate in its TLS 438 handshake certificate chain, even if that certificate is a self- 439 signed root CA and would have been optional in the context of the 440 existing public CA PKI. 442 4.2.3. Trust anchor public keys 444 TLSA records with TLSA Certificate Usage DANE-TA(2), selector SPKI(1) 445 and a matching type of Full(0) will publish the full public key of a 446 trust anchor via DNS. In section 6.1.1 of [RFC5280] the definition 447 of a trust anchor consists of the following four parts: 449 1. the trusted issuer name, 451 2. the trusted public key algorithm, 453 3. the trusted public key, and 455 4. optionally, the trusted public key parameters associated with the 456 public key. 458 Items 2-4 are precisely the contents of the subjectPublicKeyInfo 459 published in the TLSA record. The issuer name is not included in the 460 subjectPublicKeyInfo. 462 With TLSA Certificate Usage DANE-TA(2), the client may not have the 463 associated trust anchor certificate, and cannot generally verify 464 whether a particular certificate chain is "issued by" the trust 465 anchor described in the TLSA record. 467 When the server certificate chain includes a CA certificate whose 468 public key matches the TLSA record, the client can match that CA as 469 the intended issuer. Otherwise, the client can only check that the 470 topmost certificate in the server's chain is "signed by" the trust 471 anchor's public key in the TLSA record. Such a check may be 472 difficult to implement, and cannot be expected to be supported by all 473 clients. 475 Thus, servers should not rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA 476 records to be sufficient to authenticate chains issued by the 477 associated public key in the absence of a corresponding certificate 478 in the server's TLS certificate message. Servers SHOULD include the 479 TA certificate in their certificate chain. 481 If none of the server's certificate chain elements match a public key 482 specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1) 483 Full(0)" TLSA record is available, clients are encouraged to check 484 whether the topmost certificate in the chain is signed by the 485 provided public key and has not expired, and in that case consider 486 the server authenticated, provided the rest of the chain passes 487 validation including leaf certificate name checks. 489 4.3. Certificate Usage PKIX-EE(1) 491 This Certificate Usage is similar to DANE-EE(3), but in addition PKIX 492 verification is required. Therefore, name checks, certificate 493 expiration, etc., apply as they would without DANE. When, for a 494 given application protocol, DANE clients support both DANE-EE(3) and 495 PKIX-EE(1) usages, it should be noted that an attacker who can 496 compromise DNSSEC can replace these with usage DANE-EE(3) or DANE- 497 TA(2) TLSA records of their choosing, and thus bypass any PKIX 498 verification requirements. 500 Therefore, except when applications support only the PKIX Certificate 501 Usages (0 and 1), this Certificate Usage offers only illusory 502 incremental security over usage DANE-EE(3). It provides lower 503 operational reliability than DANE-EE(3) since some clients may not be 504 configured with the required root CA, the server's chain may be 505 incomplete or name checks may fail. PKIX-EE(1) also requires more 506 complex coordination between the Customer Domain and the Service 507 Provider in hosting arrangements. This certificate usage is NOT 508 RECOMMENDED. 510 4.4. Certificate Usage PKIX-TA(0) 512 This section updates [RFC6698] by specifying new client 513 implementation requirements. Clients that trust intermediate 514 certificates MUST be prepared to construct longer PKIX chains than 515 would be required for PKIX alone. 517 TLSA Certificate Usage PKIX-TA(0) allows a domain to publish 518 constraints on the set of PKIX certification authorities trusted to 519 issue certificates for its TLS servers. This TLSA record matches 520 PKIX-verified trust chains which contain an issuer certificate (root 521 or intermediate) that matches its association data field (typically a 522 certificate or digest). 524 As with PKIX-EE(1) case, an attacker who can compromise DNSSEC can 525 replace these with usage DANE-EE(3) or DANE-TA(2) TLSA records of his 526 choosing and thus bypass the PKIX verification requirements. 527 Therefore, except when applications support only the PKIX Certificate 528 Usages (0 and 1), this Certificate Usage offers only illusory 529 incremental security over usage DANE-TA(2). It provides lower 530 operational reliability than DANE-TA(2) since some clients may not be 531 configured with the required root CA. PKIX-TA(0) also requires more 532 complex coordination between the Customer Domain and the Service 533 Provider in hosting arrangements. This certificate usage is NOT 534 RECOMMENDED. 536 TLSA Publishers who publish TLSA records for a particular public root 537 CA, will expect that clients will then only accept chains anchored at 538 that root. It is possible, however, that the client's trusted 539 certificate store includes some intermediate CAs, either with or 540 without the corresponding root CA. When a client constructs a trust 541 chain leading from a trusted intermediate CA to the server leaf 542 certificate, such a "truncated" chain might not contain the trusted 543 root published in the server's TLSA record. 545 If the omitted root is also trusted, the client may erroneously 546 reject the server chain if it fails to determine that the shorter 547 chain it constructed extends to a longer trusted chain that matches 548 the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record, 549 a client SHOULD NOT always stop extending the chain when the first 550 locally trusted certificate is found. If no TLSA records have 551 matched any of the elements of the chain, and the trusted certificate 552 found is not self-issued, the client MUST attempt to build a longer 553 chain in the hope that a certificate closer to the root may in fact 554 match the server's TLSA record. 556 4.5. Opportunistic Security and PKIX usages 557 When the client's protocol design is based on Opportunistic Security 558 (OS, [I-D.dukhovni-opportunistic-security]), and authentication is 559 opportunistically employed based on the presence of server TLSA 560 records, it is especially important to avoid the PKIX-EE(1) and PKIX- 561 TA(0) certificate usages. This is because the client has no way to 562 know in advance that it and the server both trust the requisite root 563 CA. Use of authentication in OS needs to be employed only when the 564 client can be confident of success, absent an attack, or an 565 operational error on the server side. 567 5. Service Provider and TLSA Publisher Synchronization 569 Complications arise when the TLSA Publisher is not the same entity as 570 the Service Provider. In this situation, the TLSA Publisher and the 571 Service Provider must cooperate to ensure that TLSA records published 572 by the TLSA Publisher don't fall out of sync with the server 573 certificate used by the Service Provider. 575 Whenever possible, the TLSA Publisher and the Service Provider should 576 be the same entity. Otherwise, changes in the service certificate 577 chain must be carefully coordinated between the parties involved. 578 Such coordination is difficult and service outages will result when 579 coordination fails. 581 Having the master TLSA record in the Service Provider's zone avoids 582 the complexity of bilateral coordination of server certificate 583 configuration and TLSA record management. Even when the TLSA RRset 584 must be published in the Customer Domain's DNS zone (perhaps the 585 client application does not "chase" CNAMEs to the TLSA base domain), 586 it is possible to employ CNAME records to delegate the content of the 587 TLSA RRset to a domain operated by the Service Provider. Certificate 588 name checks generally constrain the applicability of TLSA CNAMEs 589 across organizational boundaries to Certificate Usages DANE-EE(3) and 590 DANE-TA(2): 592 Certificate Usage DANE-EE(3): In this case the Service Provider can 593 publish a single TLSA RRset that matches the server certificate or 594 public key digest. The same RRset works for all Customer Domains 595 because name checks do not apply with DANE-EE(3) TLSA records (see 596 Section 4.1). A Customer Domain can create a CNAME record 597 pointing to the TLSA RRset published by the Service Provider. 599 Certificate Usage DANE-TA(2): When the Service Provider operates a 600 private certification authority, the Service Provider is free to 601 issue a certificate bearing any customer's domain name. Without 602 DANE, such a certificate would not pass trust verification, but 603 with DANE, the customer's TLSA RRset that is aliased to the 604 provider's TLSA RRset can delegate authority to the provider's CA 605 for the corresponding service. The Service Provider can generate 606 appropriate certificates for each customer and use the SNI 607 information provided by clients to select the right certificate 608 chain to present to each client. 610 Below are example DNS records (assumed "secure" and shown without the 611 associated DNSSEC information, such as record signatures) that 612 illustrate both of of the above models in the case of an HTTPS 613 service whose clients all support DANE TLS. These examples work even 614 with clients that don't "chase" CNAMEs when constructing the TLSA 615 base domain (see Section 6 below). 617 ; The hosted web service is redirected via a CNAME alias. 618 ; The associated TLSA RRset is also redirected via a CNAME alias. 619 ; 620 ; A single certificate at the provider works for all Customer 621 ; Domains due to the use of the DANE-EE(3) Certificate Usage. 622 ; 623 www1.example.com. IN CNAME w1.example.net. 624 _443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net. 625 _443._tcp.w1.example.net. IN TLSA DANE-EE SPKI SHA2-256 ( 626 8A9A70596E869BED72C69D97A8895DFA 627 D86F300A343FECEFF19E89C27C896BC9 ) 629 ; 630 ; A CA at the provider can also issue certificates for each Customer 631 ; Domain, and use the DANE-TA(2) Certificate Usage type to 632 ; indicate a trust anchor. 633 ; 634 www2.example.com. IN CNAME w2.example.net. 635 _443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net. 636 _443._tcp.w2.example.net. IN TLSA DANE-TA Cert SHA2-256 ( 637 C164B2C3F36D068D42A6138E446152F5 638 68615F28C69BD96A73E354CAC88ED00C ) 640 With protocols that support explicit transport redirection via DNS MX 641 records, SRV records, or other similar records, the TLSA base domain 642 is based on the redirected transport end-point, rather than the 643 origin domain. With SMTP, for example, when an email service is 644 hosted by a Service Provider, the Customer Domain's MX hostnames will 645 point at the Service Provider's SMTP hosts. When the Customer 646 Domain's DNS zone is signed, the MX hostnames can be securely used as 647 the base domains for TLSA records that are published and managed by 648 the Service Provider. For example (without the required DNSSEC 649 information, such as record signatures): 651 ; Hosted SMTP service 652 ; 653 example.com. IN MX 0 mx1.example.net. 654 example.com. IN MX 0 mx2.example.net. 655 _25._tcp.mx1.example.net. IN TLSA DANE-EE SPKI SHA2-256 ( 656 8A9A70596E869BED72C69D97A8895DFA 657 D86F300A343FECEFF19E89C27C896BC9 ) 658 _25._tcp.mx2.example.net. IN TLSA DANE-EE SPKI SHA2-256 ( 659 C164B2C3F36D068D42A6138E446152F5 660 68615F28C69BD96A73E354CAC88ED00C ) 662 If redirection to the Service Provider's domain (via MX or SRV 663 records or any similar mechanism) is not possible, and aliasing of 664 the TLSA record is not an option, then more complex coordination 665 between the Customer Domain and Service Provider will be required. 666 Either the Customer Domain periodically provides private keys and a 667 corresponding certificate chain to the Provider (after making 668 appropriate changes in its TLSA records), or the Service Provider 669 periodically generates the keys and certificates and must wait for 670 matching TLSA records to be published by its Customer Domains before 671 deploying newly generated keys and certificate chains. In Section 6 672 below, we describe an approach that employs CNAME "chasing" to avoid 673 the difficulties of coordinating key management across organization 674 boundaries. 676 For further information about combining DANE and SRV, please see 677 [I-D.ietf-dane-srv]. 679 6. TLSA Base Domain and CNAMEs 681 When the application protocol does not support service location 682 indirection via MX, SRV or similar DNS records, the service may be 683 redirected via a CNAME. A CNAME is a more blunt instrument for this 684 purpose, since unlike an MX or SRV record, it remaps the entire 685 origin domain to the target domain for all protocols. 687 The complexity of coordinating key management is largely eliminated 688 when DANE TLSA records are found in the Service Provider's domain, as 689 discussed in Section 5. Therefore, DANE TLS clients connecting to a 690 server whose domain name is a CNAME alias SHOULD follow the CNAME 691 hop-by-hop to its ultimate target host (noting at each step whether 692 the CNAME is DNSSEC-validated). If at each stage of CNAME expansion 693 the DNSSEC validation status is "secure", the final target name 694 SHOULD be the preferred base domain for TLSA lookups. 696 Implementations failing to find a TLSA record using a base name of 697 the final target of a CNAME expansion SHOULD issue a TLSA query using 698 the original destination name. That is, the preferred TLSA base 699 domain should be derived from the fully expanded name, and failing 700 that should be the initial domain name. 702 When the TLSA base domain is the result of "secure" CNAME expansion, 703 the resulting domain name MUST be used as the HostName in SNI, and 704 MUST be the primary reference identifier for peer certificate 705 matching with certificate usages other than DANE-EE(3). 707 Protocol-specific TLSA specifications may provide additional guidance 708 or restrictions when following CNAME expansions. 710 Though CNAMEs are illegal on the right hand side of most indirection 711 records, such as MX and SRV records, they are supported by some 712 implementations. For example, if the MX or SRV host is a CNAME 713 alias, some implementations may "chase" the CNAME. If they do, they 714 SHOULD use the target hostname as the preferred TLSA base domain as 715 described above (and if the TLSA records are found there, use the 716 CNAME expanded domain also in SNI and certificate name checks). 718 7. TLSA Publisher Requirements 720 This section updates [RFC6698] by specifying a requirement on the 721 TLSA Publisher to ensure that each combination of Certificate Usage, 722 selector and matching type in the server's TLSA RRset MUST include at 723 least one record that matches the server's current certificate chain. 724 TLSA records that match recently retired or yet to be deployed 725 certificate chains will be present during key rollover. Such past or 726 future records must never be the only records published for any given 727 combination of usage, selector and matching type. We describe a TLSA 728 record update algorithm that ensures this requirement is met. 730 While a server is to be considered authenticated when its certificate 731 chain is matched by any of the published TLSA records, not all 732 clients support all combinations of TLSA record parameters. Some 733 clients may not support some digest algorithms, others may either not 734 support, or may exclusively support, the PKIX Certificate Usages. 735 Some clients may prefer to negotiate [I-D.ietf-tls-oob-pubkey] raw 736 public keys, which are only compatible with TLSA records whose 737 Certificate Usage is DANE-EE(3) with selector SPKI(1). 739 A consequence of the above uncertainty as to which TLSA parameters 740 are supported by any given client is that servers need to ensure that 741 each and every parameter combination that appears in the TLSA RRset 742 is, on its own, sufficient to match the server's current certificate 743 chain. In particular, when deploying new keys or new parameter 744 combinations some care is required to not generate parameter 745 combinations that only match past or future certificate chains (or 746 raw public keys). The rest of this section explains how to update 747 the TLSA RRset in a manner that ensures the above requirement is met. 749 7.1. Key rollover with fixed TLSA Parameters 751 The simplest case is key rollover while retaining the same set of 752 published parameter combinations. In this case, TLSA records 753 matching the existing server certificate chain (or raw public keys) 754 are first augmented with corresponding records matching the future 755 keys, at least two TTLs or longer before the the new chain is 756 deployed. This allows the obsolete RRset to age out of client caches 757 before the new chain is used in TLS handshakes. Once sufficient time 758 has elapsed and all clients performing DNS lookups are retrieving the 759 updated TLSA records, the server administrator may deploy the new 760 certificate chain, verify that it works, and then remove any obsolete 761 records matching the no longer active chain: 763 ; The initial TLSA RRset 764 ; 765 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 767 ; The transitional TLSA RRset published at least 2*TTL seconds 768 ; before the actual key change 769 ; 770 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 771 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 773 ; The final TLSA RRset after the key change 774 ; 775 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 777 The next case to consider is adding or switching to a new combination 778 of TLSA parameters. In this case publish the new parameter 779 combinations for the server's existing certificate chain first, and 780 only then deploy new keys if desired: 782 ; Initial TLSA RRset 783 ; 784 _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46... 786 ; New TLSA RRset, same key re-published as DANE-EE(3) 787 ; 788 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 790 7.2. Switching to DANE-TA from DANE-EE 792 A more complex involves switching to a trust-anchor or PKIX usage 793 from a chain that is either self-signed, or issued by a private CA 794 and thus not compatible with PKIX. Here the process is to first add 795 TLSA records matching the future chain that is issued by the desired 796 future CA (private or PKIX), but initially with the same parameters 797 as the legacy chain. Then, after deploying the new keys, switch to 798 the new TLSA parameter combination. 800 ; The initial TLSA RRset 801 ; 802 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 804 ; A transitional TLSA RRset, published at least 2*TTL before the 805 ; actual key change. The new keys are issued by a DANE-TA(2) CA, 806 ; but for now specified via a DANE-EE(3) association. 807 ; 808 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 809 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 811 ; The final TLSA RRset after the key change. Now that the old 812 ; self-signed EE keys are not an impediment, specify the issuing 813 ; TA of the new keys. 814 ; 815 _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d... 817 7.3. Switching to New TLSA Parameters 819 When employing a new digest algorithm in the TLSA RRset, for 820 compatibility with digest agility specified in Section 8 below, 821 administrators should publish the new digest algorithm with each 822 combinations of Certificate Usage and selector for each associated 823 key or chain used with any other digest algorithm. When removing an 824 algorithm, remove it entirely. Each digest algorithm employed should 825 match the same set of chains (or raw public keys). 827 ; The initial TLSA RRset with EE SHA2-256 associations for two keys. 828 ; 829 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 830 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 832 ; The new TLSA RRset also with SHA2-512 associations for each key 833 ; 834 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 835 _443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc... 836 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 837 _443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714... 839 7.4. TLSA Publisher Requirements Summary 841 In summary, server operators updating TLSA records should make one 842 change at a time. The individual safe changes are: 844 o Pre-publish new certificate associations that employ the same TLSA 845 parameters (usage, selector and matching type) as existing TLSA 846 records, but match certificate chains that will be deployed in the 847 near future. Wait for stale TLSA RRsets to expire from DNS caches 848 before configuring servers to use the new certificate chain. 850 o Remove TLSA records matching no longer deployed certificate 851 chains. 853 o Extend the TLSA RRset with a new combination of parameters (usage, 854 selector and matching type) that is used to generate matching 855 associations for all certificate chains that are published with 856 some other parameter combination. 858 The above steps are intended to ensure that at all times and for each 859 combination of usage, selector and matching type at least one TLSA 860 record corresponds to the server's current certificate chain. No 861 combination of Certificate Usage, selector and matching type in a 862 server's TLSA RRset should ever match only some combination of future 863 or past certificate chains. As a result, no matter what combinations 864 of usage, selector and matching type may be supported by a given 865 client, they will be sufficient to authenticate the server. 867 8. Digest Algorithm Agility 868 While [RFC6698] specifies multiple digest algorithms, it does not 869 specify a protocol by which the TLS client and TLSA record publisher 870 can agree on the strongest shared algorithm. Such a protocol would 871 allow the client and server to avoid exposure to any deprecated 872 weaker algorithms that are published for compatibility with less 873 capable clients, but should be ignored when possible. We specify 874 such a protocol below. 876 Suppose that a DANE TLS client authenticating a TLS server considers 877 digest algorithm "BetterAlg" stronger than digest algorithm 878 "WorseAlg". Suppose further that a server's TLSA RRset contains some 879 records with "BetterAlg" as the digest algorithm. Suppose also that 880 the server adheres to the requirements of Section 7 and ensures that 881 each combination of TLSA parameters contains at least one record that 882 matches the server's current certificate chain (or raw public keys). 883 Under the above assumptions the client can safely ignore TLSA records 884 with the weaker algorithm "WorseAlg", because it suffices to only 885 check the records with the stronger algorithm "BetterAlg". 887 To make digest algorithm agility possible, all published TLSA RRsets 888 for use with DANE TLS MUST conform to the requirements of Section 7. 889 With servers publishing compliant TLSA RRsets, TLS clients can, for 890 each combination of usage and selector, ignore all digest records 891 except those that employ their notion of the strongest digest 892 algorithm. (The server should only publish algorithms it deems 893 acceptable at all.) The ordering of digest algorithms by strength is 894 not specified in advance; it is entirely up to the TLS client. TLS 895 client implementations SHOULD make the digest algorithm preference 896 ordering a configurable option. 898 Note, TLSA records with a matching type of Full(0) that publish an 899 entire certificate or public key object play no role in digest 900 algorithm agility. They neither trump the processing of records that 901 employ digests, nor are they ignored in the presence of any records 902 with a digest (i.e. non-zero) matching type. 904 TLS clients SHOULD use digest algorithm agility when processing the 905 DANE TLSA records of an TLS server. Algorithm agility is to be 906 applied after first discarding any unusable or malformed records 907 (unsupported digest algorithm, or incorrect digest length). Thus, 908 for each usage and selector, the client SHOULD process only any 909 usable records with a matching type of Full(0) and the usable records 910 whose digest algorithm is considered by the client to be the 911 strongest among usable records with the given usage and selector. 913 9. General DANE Guidelines 914 These guidelines provide guidance for using or designing protocols 915 for DANE. 917 9.1. DANE DNS Record Size Guidelines 919 Selecting a combination of TLSA parameters to use requires careful 920 thought. One important consideration to take into account is the 921 size of the resulting TLSA record after its parameters are selected. 923 9.1.1. UDP and TCP Considerations 925 Deployments SHOULD avoid TLSA record sizes that cause UDP 926 fragmentation. 928 Although DNS over TCP would provide the ability to more easily 929 transfer larger DNS records between clients and servers, it is not 930 universally deployed and is still prohibited by some firewalls. 931 Clients that request DNS records via UDP typically only use TCP upon 932 receipt of a truncated response in the DNS response message sent over 933 UDP. Setting the TC bit alone will be insufficient if the response 934 containing the TC bit is itself fragmented. 936 9.1.2. Packet Size Considerations for TLSA Parameters 938 Server operators SHOULD NOT publish TLSA records using both a TLSA 939 Selector of Cert(0) and a TLSA Matching Type of Full(0), as even a 940 single certificate is generally too large to be reliably delivered 941 via DNS over UDP. Furthermore, two TLSA records containing full 942 certificates will need to be published simultaneously during a 943 certificate rollover, as discussed in Section 7.1. 945 While TLSA records using a TLSA Selector of SPKI(1) and a TLSA 946 Matching Type of Full(0) (which publish the bare public keys without 947 the overhead of a containing X.509 certificate) are generally more 948 compact, these too should be used with caution as they are still 949 larger than necessary. Rather, servers SHOULD publish digest-based 950 TLSA Matching Types in their TLSA records. The complete 951 corresponding certificate should, instead, be transmitted to the 952 client in-band during the TLS handshake, which can be easily verified 953 using the digest value. 955 In summary, the use of a TLSA Matching Type of Full(0) is NOT 956 RECOMMENDED and the use of a digest-based matching type, such as 957 SHA2-256(1) SHOULD be used. 959 9.2. Certificate Name Check Conventions 960 Certificates presented by a TLS server will generally contain a 961 subjectAltName (SAN) extension or a Common Name (CN) element within 962 the subject distinguished name (DN). The TLS server's DNS domain 963 name is normally published within these elements, ideally within the 964 subjectAltName extension. (The use of the CN field for this purpose 965 is deprecated.) 967 When a server hosts multiple domains at the same transport endpoint, 968 the server's ability to respond with the right certificate chain is 969 predicated on correct SNI information from the client. DANE clients 970 MUST send the SNI extension with a HostName value of the base domain 971 of the TLSA RRset. 973 Except with TLSA Certificate Usage DANE-EE(3), where name checks are 974 not applicable (see Section 4.1), DANE clients MUST verify that the 975 client has reached the correct server by checking that the server 976 name is listed in the server certificate's SAN or CN. The server 977 name used for this comparison SHOULD be the base domain of the TLSA 978 RRset. Additional acceptable names may be specified by protocol- 979 specific DANE standards. For example, with SMTP both the destination 980 domain name and the MX host name are acceptable names to be found in 981 the server certificate (see [I-D.ietf-dane-smtp-with-dane]). 983 It is the responsibility of the service operator, in coordination 984 with the TLSA Publisher, to ensure that at least one of the TLSA 985 records published for the service will match the server's certificate 986 chain (either the default chain or the certificate that was selected 987 based on the SNI information provided by the client). 989 Given the DNSSEC validated DNS records below: 991 example.com. IN MX 0 mail.example.com. 992 mail.example.com. IN A 192.0.2.1 993 _25._tcp.mail.example.com. IN TLSA DANE-TA Cert SHA2-256 ( 994 E8B54E0B4BAA815B06D3462D65FBC7C0 995 CF556ECCF9F5303EBFBB77D022F834C0 ) 997 The TLSA base domain is "mail.example.com" and is required to be the 998 HostName in the client's SNI extension. The server certificate chain 999 is required to be be signed by a trust anchor with the above 1000 certificate SHA2-256 digest. Finally, one of the DNS names in the 1001 server certificate is required to be be either "mail.example.com" or 1002 "example.com" (this additional name is a concession to compatibility 1003 with prior practice, see [I-D.ietf-dane-smtp-with-dane] for details). 1005 The semantics of wildcards in server certificates are left to 1006 individual application protocol specifications. 1008 9.3. Design Considerations for Protocols Using DANE 1010 When a TLS client goes to the trouble of authenticating a certificate 1011 chain presented by a TLS server, it will typically not continue to 1012 use that server in the event of authentication failure, or else 1013 authentication serves no purpose. Some clients may, at times, 1014 operate in an "audit" mode, where authentication failure is reported 1015 to the user or in logs as a potential problem, but the connection 1016 proceeds despite the failure. Nevertheless servers publishing TLSA 1017 records MUST be configured to allow correctly configured clients to 1018 successfully authenticate their TLS certificate chains. 1020 A service with DNSSEC-validated TLSA records implicitly promises TLS 1021 support. When all the TLSA records for a service are found 1022 "unusable", due to unsupported parameter combinations or malformed 1023 associated data, DANE clients cannot authenticate the service 1024 certificate chain. When authenticated TLS is dictated by the 1025 application, the client SHOULD NOT connect to the associated server. 1026 If, on the other hand, the use of TLS is "opportunistic", then the 1027 client SHOULD generally use the server via an unauthenticated TLS 1028 connection, but if TLS encryption cannot be established, the client 1029 MUST NOT use the server. Standards for DANE specific to the 1030 particular application protocol may modify the above requirements, as 1031 appropriate, to specify whether the connection should be established 1032 anyway without relying on TLS security, with only encryption but not 1033 authentication, or whether to refuse to connect entirely. 1034 Application protocols need to specify when to prioritize security 1035 over the ability to connect under adverse conditions. 1037 9.3.1. Design Considerations for non-PKIX Protocols 1039 For some application protocols (such as SMTP to MX with opportunistic 1040 TLS), the existing public CA PKI is not a viable alternative to DANE. 1041 For these (non-PKIX) protocols, new DANE standards SHOULD NOT suggest 1042 publishing TLSA records with TLSA Certificate Usage PKIX-TA(0) or 1043 PKIX-EE(1), as TLS clients cannot be expected to perform [RFC5280] 1044 PKIX validation or [RFC6125] identity verification. 1046 Protocols designed for non-PKIX use SHOULD choose to treat any TLSA 1047 records with TLSA Certificate Usage PKIX-TA(0) or PKIX-EE(1) as 1048 unusable. After verifying that the only available TLSA Certificate 1049 Usage types are PKIX-TA(0) or PKIX-EE(1), protocol specifications MAY 1050 instruct clients to either refuse to initiate a connection or to 1051 connect via unauthenticated TLS if no alternative authentication 1052 mechanisms are available. 1054 10. Interaction with Certificate Transparency 1055 Certificate Transparency (CT) [RFC6962] defines an experimental 1056 approach to mitigate the risk of rogue or compromised public CAs 1057 issuing unauthorized certificates. This section clarifies the 1058 interaction of CT and DANE. CT is an experimental protocol and 1059 auditing system that applies only to public CAs, and only when they 1060 are free to issue unauthorized certificates for a domain. If the CA 1061 is not a public CA, or a DANE-EE(3) TLSA RR directly specifies the 1062 end entity certificate, there is no role for CT, and clients need not 1063 apply CT checks. 1065 When a server is authenticated via a DANE TLSA RR with TLSA 1066 Certificate Usage DANE-EE(3), the domain owner has directly specified 1067 the certificate associated with the given service without reference 1068 to any PKIX certification authority. Therefore, when a TLS client 1069 authenticates the TLS server via a TLSA certificate association with 1070 usage DANE-EE(3), CT checks SHOULD NOT be performed. Publication of 1071 the server certificate or public key (digest) in a TLSA record in a 1072 DNSSEC signed zone by the domain owner assures the TLS client that 1073 the certificate is not an unauthorized certificate issued by a rogue 1074 CA without the domain owner's consent. 1076 When a server is authenticated via a DANE TLSA RR with TLSA usage 1077 DANE-TA(2) and the server certificate does not chain to a known 1078 public root CA, CT cannot apply (CT logs only accept chains that 1079 start with a known, public root). Since TLSA Certificate Usage DANE- 1080 TA(2) is generally intended to support non-PKIX trust anchors, TLS 1081 clients SHOULD NOT perform CT checks with usage DANE-TA(2) using 1082 unknown root CAs. 1084 A server operator who wants clients to perform CT checks should 1085 publish TLSA RRs with usage PKIX-TA(0) or PKIX-EE(1). 1087 11. Note on DNSSEC Security 1089 Clearly the security of the DANE TLSA PKI rests on the security of 1090 the underlying DNSSEC infrastructure. While this memo is not a guide 1091 to DNSSEC security, a few comments may be helpful to TLSA 1092 implementers. 1094 With the existing public CA PKI, name constraints are rarely used, 1095 and a public root CA can issue certificates for any domain of its 1096 choice. With DNSSEC, under the Registry/Registrar/Registrant model, 1097 the situation is different: only the registrar of record can update a 1098 domain's DS record in the registry parent zone (in some cases, 1099 however, the registry is the sole registrar). With many gTLDs, for 1100 which multiple registrars compete to provide domains in a single 1101 registry, it is important to make sure that rogue registrars cannot 1102 easily initiate an unauthorized domain transfer, and thus take over 1103 DNSSEC for the domain. DNS Operators SHOULD use a registrar lock of 1104 their domains to offer some protection against this possibility. 1106 When the registrar is also the DNS operator for the domain, one needs 1107 to consider whether the registrar will allow orderly migration of the 1108 domain to another registrar or DNS operator in a way that will 1109 maintain DNSSEC integrity. TLSA Publishers SHOULD ensure their 1110 registrar publishes a suitable domain transfer policy. 1112 DNSSEC signed RRsets cannot be securely revoked before they expire. 1113 Operators should plan accordingly and not generate signatures with 1114 excessively long duration periods. For domains publishing high-value 1115 keys, a signature lifetime of a few days is reasonable, and the zone 1116 should be resigned daily. For domains with less critical data, a 1117 reasonable signature lifetime is a couple of weeks to a month, and 1118 the zone should be resigned weekly. Monitoring of the signature 1119 lifetime is important. If the zone is not resigned in a timely 1120 manner, one risks a major outage and the entire domain will become 1121 bogus. 1123 12. Summary of Updates to RFC6698 1125 Authors note: is this section needed? Or is it sufficiently clear 1126 above that we don't need to restate things here? 1128 o In Section 3 we update [RFC6698] to specify a requirement for 1129 clients to support at least TLS 1.0, and to support SNI. 1131 o In Section 4.1 we update [RFC6698] to specify peer identity 1132 matching and certificate validity interval based solely on the 1133 basis of the TLSA RRset. We also specify DANE authentication of 1134 raw public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with 1135 Certificate Usage DANE-EE(3) and selector SPKI(1). 1137 o In Section 4.2 we update [RFC6698] to require that servers 1138 publishing digest TLSA records with a usage of DANE-TA(2) MUST 1139 include the trust-anchor certificate in their TLS server 1140 certificate message. This extends to the case of "2 1 0" TLSA 1141 records which publish a full public key. 1143 o In Section 4.3 and Section 4.4, we explain that PKIX-EE(1) and 1144 PKIX-TA(0) are generally NOT RECOMMENDED. With usage PKIX-TA(0) 1145 we note that clients may need to processes extended trust chains 1146 beyond the first trusted issuer, when that issuer is not self- 1147 signed. 1149 o In Section 6, we recommend that DANE application protocols specify 1150 that when possible securely CNAME expanded names be used to derive 1151 the TLSA base domain. 1153 o In Section 7, we specify a strategy for managing TLSA records that 1154 interoperates with DANE clients regardless of what subset of the 1155 possible TLSA record types (combinations of TLSA parameters) is 1156 supported by the client. 1158 o In Section 8, we propose a digest algorithm agility protocol. 1159 [Note: This section does not yet represent the rough consensus of 1160 the DANE working group and requires further discussion. Perhaps 1161 this belongs in a separate document.] 1163 o In Section 9.1 we recommend against the use of Full(0) TLSA 1164 records, as digest records are generally much more compact. 1166 13. Security Considerations 1168 Application protocols that cannot make use of the existing public CA 1169 PKI (so called non-PKIX protocols), may choose not to implement 1170 certain PKIX-dependent TLSA record types defined in [RFC6698]. If 1171 such records are published despite not being supported by the 1172 application protocol, they are treated as "unusable". When TLS is 1173 opportunistic, the client may proceed to use the server with 1174 mandatory unauthenticated TLS. This is stronger than opportunistic 1175 TLS without DANE, since in that case the client may also proceed with 1176 a plaintext connection. When TLS is not opportunistic, the client 1177 MUST NOT connect to the server. 1179 Therefore, when TLSA records are used with protocols where PKIX does 1180 not apply, the recommended policy is for servers to not publish PKIX- 1181 dependent TLSA records, and for opportunistic TLS clients to use them 1182 to enforce the use of (albeit unauthenticated) TLS, but otherwise 1183 treat them as unusable. Of course, when PKIX validation is supported 1184 by the application protocol, clients SHOULD perform PKIX validation 1185 per [RFC6698]. 1187 14. IANA Considerations 1189 This specification requires no support from IANA. 1191 15. Acknowledgements 1193 The authors would like to thank Phil Pennock for his comments and 1194 advice on this document. 1196 Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded 1197 me into participating in DANE working group discussions. Thanks to 1198 Paul Hoffman who motivated me to produce this memo and provided 1199 feedback on early drafts. Thanks also to Samuel Dukhovni for 1200 editorial assistance. 1202 16. References 1204 16.1. Normative References 1206 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1207 Requirement Levels", BCP 14, RFC 2119, March 1997. 1209 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1210 Rose, "DNS Security Introduction and Requirements", RFC 1211 4033, March 2005. 1213 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1214 Rose, "Resource Records for the DNS Security Extensions", 1215 RFC 4034, March 2005. 1217 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1218 Rose, "Protocol Modifications for the DNS Security 1219 Extensions", RFC 4035, March 2005. 1221 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1222 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1224 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1225 Housley, R., and W. Polk, "Internet X.509 Public Key 1226 Infrastructure Certificate and Certificate Revocation List 1227 (CRL) Profile", RFC 5280, May 2008. 1229 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1230 Extension Definitions", RFC 6066, January 2011. 1232 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1233 Verification of Domain-Based Application Service Identity 1234 within Internet Public Key Infrastructure Using X.509 1235 (PKIX) Certificates in the Context of Transport Layer 1236 Security (TLS)", RFC 6125, March 2011. 1238 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1239 Security Version 1.2", RFC 6347, January 2012. 1241 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1242 of Named Entities (DANE) Transport Layer Security (TLS) 1243 Protocol: TLSA", RFC 6698, August 2012. 1245 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 1246 Conversations about DNS-Based Authentication of Named 1247 Entities (DANE)", RFC 7218, April 2014. 1249 16.2. Informative References 1251 [I-D.dukhovni-opportunistic-security] 1252 Dukhovni, V., "Opportunistic Security: Some Protection 1253 Most of the Time", draft-dukhovni-opportunistic- 1254 security-03 (work in progress), August 2014. 1256 [I-D.ietf-dane-smtp-with-dane] 1257 Dukhovni, V. and W. Hardaker, "SMTP security via 1258 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-11 1259 (work in progress), August 2014. 1261 [I-D.ietf-dane-srv] 1262 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 1263 Based Authentication of Named Entities (DANE) TLSA Records 1264 with SRV Records", draft-ietf-dane-srv-07 (work in 1265 progress), July 2014. 1267 [I-D.ietf-tls-oob-pubkey] 1268 Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 1269 T. Kivinen, "Using Raw Public Keys in Transport Layer 1270 Security (TLS) and Datagram Transport Layer Security 1271 (DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress), 1272 January 2014. 1274 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1275 Transparency", RFC 6962, June 2013. 1277 Authors' Addresses 1279 Viktor Dukhovni 1280 Unaffiliated 1282 Email: ietf-dane@dukhovni.org 1284 Wes Hardaker 1285 Parsons 1286 P.O. Box 382 1287 Davis, CA 95617 1288 US 1290 Email: ietf@hardakers.net