idnits 2.17.1 draft-ietf-dane-ops-05.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 (July 03, 2014) is 3584 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 (-04) exists of draft-ietf-dane-registry-acronyms-03 == Outdated reference: A later version (-19) exists of draft-ietf-dane-smtp-with-dane-06 == Outdated reference: A later version (-14) exists of draft-ietf-dane-srv-05 -- 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: January 04, 2015 Parsons 6 July 03, 2014 8 Updates to and Operational Guidance for the DANE Protocol 9 draft-ietf-dane-ops-05 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 January 04, 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 . . . 6 58 4.1. Certificate Usage DANE-EE(3) . . . . . . . . . . . . . . 6 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) . . . . . . . . . . . . . . 11 62 5. Service Provider and TLSA Publisher Synchronization . . . . . 12 63 6. TLSA Base Domain and CNAMEs . . . . . . . . . . . . . . . . . 15 64 7. TLSA Publisher Requirements . . . . . . . . . . . . . . . . . 15 65 7.1. Rolling a Key Without Changing TLSA Parameters . . . . . 16 66 7.2. Switching to DANE-CA from DANE-EE . . . . . . . . . . . . 17 67 7.3. Switching to New TLSA Parameters . . . . . . . . . . . . 17 68 7.4. TLSA Publisher Requirements Summary . . . . . . . . . . . 18 69 8. Digest Algorithm Agility . . . . . . . . . . . . . . . . . . 18 70 9. General DANE Guidelines . . . . . . . . . . . . . . . . . . . 19 71 9.1. DANE DNS Record Size Guidelines . . . . . . . . . . . . . 19 72 9.2. Certificate Name Check Conventions . . . . . . . . . . . 20 73 9.3. Design Considerations for Protocols Using DANE . . . . . 21 74 10. Interaction with Certificate Transparency . . . . . . . . . . 22 75 11. Note on DNSSEC Security . . . . . . . . . . . . . . . . . . . 23 76 12. Summary of Updates to RFC6698 . . . . . . . . . . . . . . . . 24 77 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 78 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 79 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 80 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 81 16.1. Normative References . . . . . . . . . . . . . . . . . . 25 82 16.2. Informative References . . . . . . . . . . . . . . . . . 26 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 85 1. Introduction 87 [RFC6698] specifies a new DNS resource record "TLSA" that associates 88 a public certificate or public key of a trusted leaf or issuing 89 authority with the corresponding TLS transport endpoint. These DANE 90 TLSA records, when validated by DNSSEC, can be used to augment or 91 replace the trust model of the existing public Certification 92 Authority (CA) Public Key Infrastructure (PKI). 94 [RFC6698] defines three TLSA record fields with respectively 4, 2 and 95 3 currently specified values. These yield 24 distinct combinations 96 of TLSA record types. This many options have been lead to 97 implementation and operational complexity. This memo will recommend 98 best-practice choices to help simplify implementation and deployment 99 given these plethora of choices. 101 Implementation complexity also arises from the fact that the TLS 102 transport endpoint is often specified indirectly via Service Records 103 (SRV), Mail Exchange (MX) records, CNAME records or other mechanisms 104 that map an abstract service domain to a concrete server domain. 105 With service indirection there are multiple potential places for 106 clients to find the relevant TLSA records. Service indirection is 107 often used to implement "virtual hosting", where a single Service 108 Provider transport endpoint simultaneously supports multiple hosted 109 domain names. With services that employ TLS, such hosting 110 arrangements may require the Service Provider to deploy multiple 111 pairs of private keys and certificates with TLS clients signaling the 112 desired domain via the Server Name Indication (SNI) extension 113 ([RFC6066], section 3). This memo provides operational guidelines 114 intended to maximize interoperability between DANE TLS clients and 115 servers. 117 In the context of this memo, channel security is assumed to be 118 provided by TLS or DTLS. The Transport Layer Security (TLS) 119 [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347] 120 protocols provide secured TCP and UDP communication over IP. By 121 convention, "TLS" will be used throughout this document and, unless 122 otherwise specified, the text applies equally well to the DTLS 123 protocol. Used without authentication, TLS provides protection only 124 against eavesdropping through its use of encryption. With 125 authentication, TLS also provides integrity protection and 126 authentication, which protect the transport against man-in-the-middle 127 (MITM) attacks. 129 Other related documents that build on [RFC6698] are 130 [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]. In 131 Section 12 we summarize the updates this document makes to [RFC6698]. 133 1.1. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in 138 [RFC2119]. 140 The following terms are used throughout this document: 142 Service Provider: A company or organization that offers to host a 143 service on behalf of a Customer Domain. The original domain name 144 associated with the service often remains under the control of the 145 customer. Connecting applications may be directed to the Service 146 Provider via a redirection resource record. Example redirection 147 records include MX, SRV, and CNAME. The Service Provider 148 frequently provides services for many customers and must carefully 149 manage any TLS credentials offered to connecting applications to 150 ensure name matching is handled easily by the applications. 152 Customer Domain: As described above, a client may be interacting 153 with a service that is hosted by a third party. We will refer to 154 the domain name used to locate the service prior to any 155 redirection, as the "Customer Domain". 157 TLSA Publisher: The entity responsible for publishing a TLSA record 158 within a DNS zone. This zone will be assumed DNSSEC-signed and 159 validatable to a trust anchor, unless otherwise specified. If the 160 Customer Domain is not outsourcing their DNS service, the TLSA 161 Publisher will be the customer themselves. Otherwise, the TLSA 162 Publisher is sometimes the operator of the outsourced DNS service. 164 public key: The term "public key" is short-hand for the 165 subjectPublicKeyInfo component of a PKIX [RFC5280] certificate. 167 SNI: The "Server Name Indication" (SNI) TLS protocol extension 168 allows a TLS client to request a connection to a particular 169 service name of a TLS server ([RFC6066], section 3). Without this 170 TLS extension, a TLS server has no choice but to offer a PKIX 171 certificate with a default list of server names, making it 172 difficult to host multiple Customer Domains at the same IP- 173 addressed based TLS service endpoint (i.e., "secure virtual 174 hosting"). 176 TLSA parameters: In [RFC6698] the TLSA record is defined to consist 177 of four fields. The first three of these are numberic parameters 178 that specify the meaning of the data in fourth and final field. 179 To avoid language contortions when we need to distinguish between 180 the first three fields that together define a TLSA record "type" 181 and the fourth that provides a data value of that type, we will 182 call the first three fields "TLSA parameters", or sometimes just 183 "parameters" when obvious from context. 185 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 193 [I-D.ietf-dane-registry-acronyms]. These 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) 284 In this section the meaning of DANE-EE(3) is updated from [RFC6698] 285 to specify that peer identity matching and that validity interval 286 compliance is based solely on the TLSA RRset properties. We also 287 extend [RFC6698] to cover the use of DANE authentication of raw 288 public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with 289 Certificate Usage DANE-EE(3) and selector SPKI(1). 291 Authentication via certificate usage DANE-EE(3) TLSA records involves 292 simply checking that the server's leaf certificate matches the TLSA 293 record. In particular, the binding of the server public key to its 294 name is based entirely on the TLSA record association. The server 295 MUST be considered authenticated even if none of the names in the 296 certificate match the client's reference identity for the server. 298 Similarly, with DANE-EE(3), the expiration date of the server 299 certificate MUST be ignored. The validity period of the TLSA record 300 key binding is determined by the validity interval of the TLSA record 301 DNSSEC signatures. 303 With DANE-EE(3) servers that know all the connecting clients are 304 making use of DANE, they need not employ SNI (i.e., the may ignore 305 the client's SNI message) even when the server is known under 306 multiple domain names that would otherwise require separate 307 certificates. It is instead sufficient for the TLSA RRsets for all 308 the domain names in question to match the server's primary 309 certificate. For application protocols where the server name is 310 obtained indirectly via SRV, MX or similar records, it is simplest to 311 publish a single hostname as the target server name for all the 312 hosted domains. 314 In organizations where it is practical to make coordinated changes in 315 DNS TLSA records before server key rotation, it is generally best to 316 publish end-entity DANE-EE(3) certificate associations in preference 317 to other choices of certificate usage. DANE-EE(3) TLSA records 318 support multiple server names without SNI, don't suddenly stop 319 working when leaf or intermediate certificates expire, and don't fail 320 when a server operator neglects to include all the required issuer 321 certificates in the server certificate chain. 323 TLSA records published for DANE servers SHOULD, as a best practice, 324 be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE 325 implementations are required to support SHA2-256, this record type 326 works for all clients and need not change across certificate renewals 327 with the same key. This TLSA record type easily supports hosting 328 arrangements with a single certificate matching all hosted domain. 329 It is also the easiest to implement correctly in the client. 331 Another advantage of "DANE-EE(3) SPKI(1)" (with any suitable matching 332 type) TLSA records is that they are compatible with the raw public 333 key TLS extension specified in [I-D.ietf-tls-oob-pubkey]. DANE 334 clients that support this extension can use the TLSA record to 335 authenticate servers that negotiate the use of raw public keys in 336 place of X.509 certificate chains. Provided the server adheres to 337 the requirements of Section 7, the fact that raw public keys are not 338 compatible with any other TLSA record types will not get in the way 339 of successful authentication. Clients that employ DANE to 340 authenticate the peer server SHOULD NOT negotiate the use of raw 341 public keys unless the server's TLSA RRset includes compatible TLSA 342 records. 344 While it is, in principle, also possible to authenticate raw public 345 keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the 346 public key from the certificate in DNS, this is in conflict with the 347 indicated selector and requires extra logic on clients that not all 348 implementations are expected to provide. Servers SHOULD NOT rely on 349 "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication 350 data for raw public keys. 352 4.2. Certificate Usage DANE-TA(2) 354 This section updates [RFC6698] by specifying a new operational 355 requirement for servers publishing TLSA records with a usage of DANE- 356 TA(2): such servers MUST include the trust-anchor certificate in 357 their TLS server certificate message. 359 Some domains may prefer to avoid the operational complexity of 360 publishing unique TLSA RRs for each TLS service. If the domain 361 employs a common issuing Certification Authority to create 362 certificates for multiple TLS services, it may be simpler to publish 363 the issuing authority as a trust anchor (TA) for the certificate 364 chains of all relevant services. The TLSA query domain (TLSA base 365 domain with port and protocol prefix labels) for each service issued 366 by the same TA may then be set to a CNAME alias that points to a 367 common TLSA RRset that matches the TA. For example: 369 www1.example.com. IN A 192.0.2.1 370 www2.example.com. IN A 192.0.2.2 371 _443._tcp.www1.example.com. IN CNAME tlsa201._dane.example.com. 372 _443._tcp.www2.example.com. IN CNAME tlsa201._dane.example.com. 373 tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14... 375 With usage DANE-TA(2) the server certificates will need to have names 376 that match one of the client's reference identifiers (see [RFC6125]). 377 The server SHOULD employ SNI to select the appropriate certificate to 378 present to the client. 380 4.2.1. Recommended record combinations 382 TLSA records with selector Full(0) are NOT RECOMMENDED. While these 383 potentially obviate the need to transmit the TA certificate in the 384 TLS server certificate message, client implementations may not be 385 able to augment the server certificate chain with the data obtained 386 from DNS, especially when the TLSA record supplies a bare key 387 (selector SPKI(1)). Since the server will need to transmit the TA 388 certificate in any case, server operators SHOULD publish TLSA records 389 with a selector other than Full(0) and avoid potential DNS 390 interoperability issues with large TLSA records containing full 391 certificates or keys (see Section 9.1.1). 393 TLSA Publishers employing DANE-TA(2) records SHOULD publish records 394 with a selector of Cert(0). Such TLSA records are associated with 395 the whole trust anchor certificate, not just with the trust anchor 396 public key. In particular, the client SHOULD then apply any relevant 397 constraints from the trust anchor certificate, such as, for example, 398 path length constraints. 400 While a selector of SPKI(1) may also be employed, the resulting TLSA 401 record will not specify the full trust anchor certificate content, 402 and elements of the trust anchor certificate other than the public 403 key become mutable. This may, for example, enable a subsidiary CA to 404 issue a chain that violates the trust anchor's path length or name 405 constraints. 407 4.2.2. Trust anchor digests and server certificate chain 409 With DANE-TA(2) (TLSA records should match the digest of a TA 410 certificate or public key), a complication arises when the TA 411 certificate is omitted from the server's certificate chain, perhaps 412 on the basis of Section 7.4.2 of [RFC5246]: 414 The sender's certificate MUST come first in the list. Each 415 following certificate MUST directly certify the one preceding 416 it. Because certificate validation requires that root keys be 417 distributed independently, the self-signed certificate that 418 specifies the root certification authority MAY be omitted from 419 the chain, under the assumption that the remote end must 420 already possess it in order to validate it in any case. 422 With TLSA Certificate Usage DANE-TA(2), there is no expectation that 423 the client is pre-configured with the trust anchor certificate. In 424 fact, client implementations are free to ignore all locally 425 configured trust anchors when processing usage DANE-TA(2) TLSA 426 records and may rely exclusively on the certificicates provided in 427 the server's certificate chain. But, with a digest in the TLSA 428 record, the TLSA record contains neither the full trust anchor 429 certificate nor the full public key. If the TLS server's certificate 430 chain does not contain the trust anchor certificate, DANE clients 431 will be unable to authenticate the server. 433 TLSA Publishers that publish TLSA Certificate Usage DANE-TA(2) 434 associations with a selector of SPKI(1) or using a digest-based 435 matching type (not Full(0)) MUST ensure that the corresponding server 436 is configured to also include the trust anchor certificate in its TLS 437 handshake certificate chain, even if that certificate is a self- 438 signed root CA and would have been optional in the context of the 439 existing public CA PKI. 441 4.2.3. Trust anchor public keys 443 TLSA records with TLSA Certificate Usage DANE-TA(2), selector SPKI(1) 444 and a matching type of Full(0) will publish the full public key of a 445 trust anchor via DNS. In section 6.1.1 of [RFC5280] the definition 446 of a trust anchor consists of the following four parts: 448 1. the trusted issuer name, 450 2. the trusted public key algorithm, 452 3. the trusted public key, and 454 4. optionally, the trusted public key parameters associated with the 455 public key. 457 Items 2-4 are precisely the contents of the subjectPublicKeyInfo 458 published in the TLSA record. The issuer name is not included in the 459 subjectPublicKeyInfo. 461 With TLSA Certificate Usage DANE-TA(2), the client may not have the 462 associated trust anchor certificate, and cannot generally verify 463 whether a particular certificate chain is "issued by" the trust 464 anchor described in the TLSA record. 466 When the server certificate chain includes a CA certificate whose 467 public key matches the TLSA record, the client can match that CA as 468 the intended issuer. Otherwise, the client can only check that the 469 topmost certificate in the server's chain is "signed by" the trust 470 anchor's public key in the TLSA record. Such a check may be 471 difficult to implement, and cannot be expected to be supported by all 472 clients. 474 Thus, servers should not rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA 475 records to be sufficient to authenticate chains issued by the 476 associated public key in the absense of a corresponding certificate 477 in the server's TLS certificate message. Servers SHOULD include the 478 TA certificate in their certificate chain. 480 If none of the server's certificate chain elements match a public key 481 specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1) 482 Full(0)" TLSA record is available, clients are encouraged to check 483 whether the topmost certificate in the chain is signed by the 484 provided public key and has not expired, and in that case consider 485 the server authenticated, provided the rest of the chain passes 486 validation including leaf certificate name checks. 488 4.3. Certificate Usage PKIX-EE(1) 490 This Certificate Usage is similar to DANE-EE(3), but in addition PKIX 491 verification is required. Therefore, name checks, certificate 492 expiration, etc., apply as they would without DANE. When, for a 493 given application protocol, DANE clients support both DANE-EE(3) and 494 PKIX-EE(1) usages, it should be noted that an attacker who can 495 compromise DNSSEC can replace these with usage DANE-EE(3) or DANE- 496 TA(2) TLSA records of their choosing, and thus bypass any PKIX 497 verification requirements. 499 Therefore, except when applications support only the PKIX Certificate 500 Usages (0 and 1), this Certificate Usage offers only illusory 501 incremental security over usage DANE-EE(3). It provides lower 502 operational reliability than DANE-EE(3) since some clients may not be 503 configured with the required root CA, the server's chain may be 504 incomplete or name checks may fail. PKIX-EE(1) also requires more 505 complex coordination between the Customer Domain and the Service 506 Provider in hosting arrangements. This certificate usage is NOT 507 RECOMMENDED. 509 4.4. Certificate Usage PKIX-TA(0) 511 This section updates [RFC6698] by specifying new client 512 implementation requirements. Clients that trust intermediate 513 certificates MUST be prepared to construct longer PKIX chains than 514 would be required for PKIX alone. 516 TLSA Certificate Usage PKIX-TA(0) allows a domain to publish 517 constraints on the set of PKIX certification authorities trusted to 518 issue certificates for its TLS servers. This TLSA record matches 519 PKIX-verified trust chains which contain an issuer certificate (root 520 or intermediate) that matches its association data field (typically a 521 certificate or digest). 523 As with PKIX-EE(1) case, an attacker who can compromise DNSSEC can 524 replace these with usage DANE-EE(3) or DANE-TA(2) TLSA records of his 525 choosing and thus bypass the PKIX verification requirements. 526 Therefore, except when applications support only the PKIX Certificate 527 Usages (0 and 1), this Certificate Usage offers only illusory 528 incremental security over usage DANE-TA(2). It provides lower 529 operational reliability than DANE-TA(2) since some clients may not be 530 configured with the required root CA. PKIX-TA(0) also requires more 531 complex coordination between the Customer Domain and the Service 532 Provider in hosting arrangements. This certificate usage is NOT 533 RECOMMENDED. 535 TLSA Publishers who publish TLSA records for a particular public root 536 CA, will expect that clients will then only accept chains anchored at 537 that root. It is possible, however, that the client's trusted 538 certificate store includes some intermediate CAs, either with or 539 without the corresponding root CA. When a client constructs a trust 540 chain leading from a trusted intermediate CA to the server leaf 541 certificate, such a "truncated" chain might not contain the trusted 542 root published in the server's TLSA record. 544 If the omitted root is also trusted, the client may erroneously 545 reject the server chain if it fails to determine that the shorter 546 chain it constructed extends to a longer trusted chain that matches 547 the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record, 548 a client SHOULD NOT always stop extending the chain when the first 549 locally trusted certificate is found. If no TLSA records have 550 matched any of the elements of the chain, and the trusted certificate 551 found is not self-issued, the client MUST attempt to build a longer 552 chain in the hope that a certificate closer to the root may in fact 553 match the server's TLSA record. 555 5. Service Provider and TLSA Publisher Synchronization 557 Complications arise when the TLSA Publisher is not the same entity as 558 the Service Provider. In this situation, the TLSA Publisher and the 559 Service Provider must cooperate to ensure that TLSA records published 560 by the TLSA Publisher don't fall out of sync with the server 561 certificate used by the Service Provider. 563 Whenever possible, the TLSA Publisher and the Service Provider should 564 be the same entity. Otherwise, changes in the service certificate 565 chain must be carefully coordinated between the parties involved. 566 Such coordination is difficult and service outages will result when 567 coordination fails. 569 Having the master TLSA record in the Service Provider's zone avoids 570 the complexity of bilateral coordination of server certificate 571 configuration and TLSA record management. Even when the TLSA RRset 572 must be published in the Customer Domain's DNS zone (perhaps the 573 client application does not "chase" CNAMEs to the TLSA base domain), 574 it is possible to employ CNAME records to delegate the content of the 575 TLSA RRset to a domain operated by the Service Provider. Certificate 576 name checks generally constrain the applicability of TLSA CNAMEs 577 across organizational boundaries to Certificate Usages DANE-EE(3) and 578 DANE-TA(2): 580 Certificate Usage DANE-EE(3): In this case the Service Provider can 581 publish a single TLSA RRset that matches the server certificate or 582 public key digest. The same RRset works for all Customer Domains 583 because name checks do not apply with DANE-EE(3) TLSA records (see 584 Section 4.1). A Customer Domain can create a CNAME record 585 pointing to the TLSA RRset published by the Service Provider. 587 Certificate Usage DANE-TA(2): When the Service Provider operates a 588 private certification authority, the Service Provider is free to 589 issue a certificate bearing any customer's domain name. Without 590 DANE, such a certificate would not pass trust verification, but 591 with DANE, the customer's TLSA RRset that is aliased to the 592 provider's TLSA RRset can delegate authority to the provider's CA 593 for the corresponding service. The Service Provider can generate 594 appropriate certificates for each customer and use the SNI 595 information provided by clients to select the right certificate 596 chain to present to each client. 598 Below are example DNS records (assumed "secure" and shown without the 599 associated DNSSEC information, such as record signatures) that 600 illustrate both of of the above models in the case of an HTTPS 601 service whose clients all support DANE TLS. These examples work even 602 with clients that don't "chase" CNAMEs when constructing the TLSA 603 base domain (see Section 6 below). 605 ; The hosted web service is redirected via a CNAME alias. 606 ; The associated TLSA RRset is also redirected via a CNAME alias. 607 ; 608 ; A single certificate at the provider works for all Customer 609 ; Domains due to the use of the DANE-EE(3) Certificate Usage. 610 ; 611 www1.example.com. IN CNAME w1.example.net. 612 _443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net. 613 _443._tcp.w1.example.net. IN TLSA DANE-EE SPKI SHA2-256 ( 614 8A9A70596E869BED72C69D97A8895DFA 615 D86F300A343FECEFF19E89C27C896BC9 ) 617 ; 618 ; A CA at the provider can also issue certificates for each Customer 619 ; Domain, and use the DANE-TA(2) Certificate Usage type to 620 ; indicate a trust anchor. 621 ; 622 www2.example.com. IN CNAME w2.example.net. 623 _443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net. 624 _443._tcp.w2.example.net. IN TLSA DANE-TA Cert SHA2-256 ( 625 C164B2C3F36D068D42A6138E446152F5 626 68615F28C69BD96A73E354CAC88ED00C ) 628 With protocols that support explicit transport redirection via DNS MX 629 records, SRV records, or other similar records, the TLSA base domain 630 is based on the redirected transport end-point, rather than the 631 origin domain. With SMTP, for example, when an email service is 632 hosted by a Service Provider, the Customer Domain's MX hostnames will 633 point at the Service Provider's SMTP hosts. When the Customer 634 Domain's DNS zone is signed, the MX hostnames can be securely used as 635 the base domains for TLSA records that are published and managed by 636 the Service Provider. For example (without the required DNSSEC 637 information, such as record signatures): 639 ; Hosted SMTP service 640 ; 641 example.com. IN MX 0 mx1.example.net. 642 example.com. IN MX 0 mx2.example.net. 643 _25._tcp.mx1.example.net. IN TLSA DANE-EE SPKI SHA2-256 ( 644 8A9A70596E869BED72C69D97A8895DFA 645 D86F300A343FECEFF19E89C27C896BC9 ) 646 _25._tcp.mx2.example.net. IN TLSA DANE-EE SPKI SHA2-256 ( 647 C164B2C3F36D068D42A6138E446152F5 648 68615F28C69BD96A73E354CAC88ED00C ) 650 If redirection to the Service Provider's domain (via MX or SRV 651 records or any similar mechanism) is not possible, and aliasing of 652 the TLSA record is not an option, then more complex coordination 653 between the Customer Domain and Service Provider will be required. 654 Either the Customer Domain periodically provides private keys and a 655 corresponding certificate chain to the Provider (after making 656 appropriate changes in its TLSA records), or the Service Provider 657 periodically generates the keys and certificates and must wait for 658 matching TLSA records to be published by its Customer Domains before 659 deploying newly generated keys and certificate chains. In Section 6 660 below, we describe an approach that employs CNAME "chasing" to avoid 661 the difficulties of coordinating key management across organization 662 boundaries. 664 For further information about combining DANE and SRV, please see 665 [I-D.ietf-dane-srv]. 667 6. TLSA Base Domain and CNAMEs 669 When the application protocol does not support service location 670 indirection via MX, SRV or similar DNS records, the service may be 671 redirected via a CNAME. A CNAME is a more blunt instrument for this 672 purpose, since unlike an MX or SRV record, it remaps the entire 673 origin domain to the target domain for all protocols. 675 The complexity of coordinating key management is largely eliminated 676 when DANE TLSA records are found in the Service Provider's domain, as 677 discussed in Section 5. Therefore, DANE TLS clients connecting to a 678 server whose domain name is a CNAME alias SHOULD follow the CNAME 679 hop-by-hop to its ultimate target host (noting at each step whether 680 the CNAME is DNSSEC-validated). If at each stage of CNAME expansion 681 the DNSSEC validation status is "secure", the final target name 682 SHOULD be the preferred base domain for TLSA lookups. 684 Implementations failing to find a TLSA record using a base name of 685 the final target of a CNAME expansion SHOULD issue a TLSA query using 686 the original destination name. That is, the preferred TLSA base 687 domain should be derived from the fully expanded name, and failing 688 that should be the initial domain name. 690 When the TLSA base domain is the result of "secure" CNAME expansion, 691 the resulting domain name MUST be used as the HostName in SNI, and 692 MUST be the primary reference identifier for peer certificate 693 matching with certificate usages other than DANE-EE(3). 695 Protocol-specific TLSA specifications may provide additional guidance 696 or restrictions when following CNAME expansions. 698 Though CNAMEs are illegal on the right hand side of most indirection 699 records, such as MX and SRV records, they are supported by some 700 implementations. For example, if the MX or SRV host is a CNAME 701 alias, some implementations may "chase" the CNAME. If they do, they 702 SHOULD use the target hostname as the preferred TLSA base domain as 703 described above (and if the TLSA records are found there, use the 704 CNAME expanded domain also in SNI and certificate name checks). 706 7. TLSA Publisher Requirements 708 This section updates [RFC6698] by specifying a requirement on the 709 TLSA Publisher to ensure that each combination of Certificate Usage, 710 selector and matching type that is present in the server's TLSA RRset 711 MUST include at least one record that matches the server's present 712 (rather than future or past) certificate chain. We describe a TLSA 713 record update algorithm that ensures this requirement is met. 715 While a server is to be considered authenticated when its certificate 716 chain is matched by any of the published TLSA records, not all 717 clients support all combinations of TLSA record parameters. Some 718 clients may not support some digest algorithms, others may either not 719 support, or may exclusively support, the PKIX Certificate Usages. 720 Some clients may prefer to negotiate [I-D.ietf-tls-oob-pubkey] raw 721 public keys, which are only compatible with TLSA records whose 722 Certificat Usage is DANE-EE(3) with selector SPKI(1). 724 A consequence of the above uncertainty as to which TLSA parameters 725 are supported by any given client is that servers need to ensure that 726 each and every parameter combination that appears in the TLSA RRset 727 is, on its own, sufficient to match the server's current certificate 728 chain. In particular, when deploying new keys or new parameter 729 combinations some care is required to not generate parameter 730 combinations that only match past or future certificate chains (or 731 raw public keys). The rest of this section explains how to update 732 the TLSA RRset in a manner that ensures the above requirement is met. 734 7.1. Rolling a Key Without Changing TLSA Parameters 736 The simplest case is key rollover while retaining the same set of 737 published parameter combinations. In this case, TLSA records 738 matching the existing server certificate chain (or raw public keys) 739 are first augmented with corresponding records matching the future 740 keys, at least two TTLs or longer before the the new chain is 741 deployed. This allows the obsolete RRset to age out of client caches 742 before the new chain is used in TLS handshakes. Once sufficient time 743 has elapsed and all clients performing DNS lookups are retrieving the 744 updated TLSA records, the server administrator may deploy the new 745 certificate chain, verify that it works, and then remove any obsolete 746 records matching the no longer active chain: 748 ; The initial TLSA RRset 749 ; 750 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 752 ; The transitional TLSA RRset published at least 2*TTL seconds 753 ; before the actual key change 754 ; 755 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 756 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 758 ; The final TLSA RRset after the key change 759 ; 760 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 762 The next case to consider is adding or switching to a new combination 763 of TLSA parameters. In this case publish the new parameter 764 combinations for the server's existing certificate chain first, and 765 only then deploy new keys if desired: 767 ; Initial TLSA RRset 768 ; 769 _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46... 771 ; New TLSA RRset, same key re-published as DANE-EE(3) 772 ; 773 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 775 7.2. Switching to DANE-CA from DANE-EE 777 A more complex involves switching to a trust-anchor or PKIX usage 778 from a chain that is either self-signed, or issued by a private CA 779 and thus not compatible with PKIX. Here the process is to first add 780 TLSA records matching the future chain that is issued by the desired 781 future CA (private or PKIX), but initially with the same parameters 782 as the legacy chain. Then, after deploying the new keys, switch to 783 the new TLSA parameter combination. 785 ; The initial TLSA RRset 786 ; 787 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 789 ; A transitional TLSA RRset, published at least 2*TTL before the 790 ; actual key change. The new keys are issued by a DANE-TA(2) CA, 791 ; but for now specified via a DANE-EE(3) association. 792 ; 793 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 794 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 796 ; The final TLSA RRset after the key change. Now that the old 797 ; self-signed EE keys are not an impediment, specify the issuing 798 ; TA of the new keys. 799 ; 800 _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d... 802 7.3. Switching to New TLSA Parameters 803 When employing a new digest algorithm in the TLSA RRset, for 804 compatibility with digest agility specified in Section 8 below, 805 administrators should publish the new digest algorithm with each 806 combinations of Certificate Usage and selector for each associated 807 key or chain used with any other digest algorithm. When removing an 808 algorithm, remove it entirely. Each digest algorithm employed should 809 match the same set of chains (or raw public keys). 811 ; The initial TLSA RRset with EE SHA2-256 associations for two keys. 812 ; 813 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 814 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 816 ; The new TLSA RRset also with SHA2-512 associations for each key 817 ; 818 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 819 _443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc... 820 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 821 _443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714... 823 7.4. TLSA Publisher Requirements Summary 825 In summary, server operators updating TLSA records should make one 826 change at a time. Either pre-publish new keys with existing TLSA 827 parameters, remove records matching stale keys, or add new TLSA 828 parameters for all current keys. Ensure that at all times, each 829 combination of parameter values matches the same set of underlying 830 objects (trust anchors, leaf certificates or raw public keys). 831 Another way of saying the same thing is that no combination of 832 Certificate Usage, selector and matching type in a server's TLSA 833 RRset should ever match only some combination of future or past keys. 834 Such combinations of parameters should be removed before 835 corresponding keys are retired, or added only after new keys become 836 active. 838 8. Digest Algorithm Agility 840 While [RFC6698] specifies multiple digest algorithms, it does not 841 specify a protocol by which the TLS client and TLSA record publisher 842 can agree on the strongest shared algorithm. Such a protocol would 843 allow the client and server to avoid exposure to any deprecated 844 weaker algorithms that are published for compatibility with less 845 capable clients, but should be ignored when possible. We specify 846 such a protocol below. 848 Suppose that a DANE TLS client authenticating a TLS server considers 849 digest algorithm "BetterAlg" stronger than digest algorithm 850 "WorseAlg". Suppose further that a server's TLSA RRset contains some 851 records with "BetterAlg" as the digest algorithm. Suppose also that 852 the server adheres to the requirements of Section 7 and ensures that 853 each combination of TLSA parameters contains at least one record that 854 matches the server's current certificate chain (or raw public keys). 855 Under the above assumptions the client can safely ignore TLSA records 856 with the weaker algorithm "WorseAlg", because it suffices to only 857 check the records with the stronger algorithm "BetterAlg". 859 To make digest algorithm agility possible, all published TLSA RRsets 860 for use with DANE TLS MUST conform to the requirements of Section 7. 861 With servers publishing compliant TLSA RRsets, TLS clients can, for 862 each combination of usage and selector, ignore all digest records 863 except those that employ their notion of the strongest digest 864 algorithm. (The server should only publish algorithms it deems 865 acceptable at all.) The ordering of digest algorithms by strength is 866 not specified in advance; it is entirely up to the TLS client. TLS 867 client implementations SHOULD make the digest algorithm preference 868 ordering a configurable option. 870 Note, TLSA records with a matching type of Full(0) that publish an 871 entire certificate or public key object play no role in digest 872 algorithm agility. They neither trump the processing of records that 873 employ digests, nor are they ignored in the presence of any records 874 with a digest (i.e. non-zero) matching type. 876 TLS clients SHOULD use digest algorithm agility when processing the 877 DANE TLSA records of an TLS server. Algorithm agility is to be 878 applied after first discarding any unusable or malformed records 879 (unsupported digest algorithm, or incorrect digest length). Thus, 880 for each usage and selector, the client SHOULD process only any 881 usable records with a matching type of Full(0) and the usable records 882 whose digest algorithm is considered by the client to be the 883 strongest among usable records with the given usage and selector. 885 9. General DANE Guidelines 887 These guidelines provide guidance for using or designing protocols 888 for DANE. 890 9.1. DANE DNS Record Size Guidelines 892 Selecting a combination of TLSA parameters to use requires careful 893 thought. One important consideration to take into account is the 894 size of the resulting TLSA record after its parameters are selected. 896 9.1.1. UDP and TCP Considerations 897 Deployments SHOULD avoid TLSA record sizes that cause UDP 898 fragmentation. 900 Although DNS over TCP would provide the ability to more easily 901 transfer larger DNS records between clients and servers, it is not 902 universally deployed and is still prohibited by some firewalls. 903 Clients that request DNS records via UDP typically only use TCP upon 904 receipt of a truncated response in the DNS response message sent over 905 UDP. Setting the TC bit alone will be insufficient if the response 906 containing the TC bit is itself fragmented. 908 9.1.2. Packet Size Considerations for TLSA Parameters 910 Server operators SHOULD NOT publish TLSA records using both a TLSA 911 Selector of Cert(0) and a TLSA Matching Type of Full(0), as even a 912 single certificate is generally too large to be reliably delivered 913 via DNS over UDP. Furthermore, two TLSA records containing full 914 certificates will need to be published simultaneously during a 915 certificate rollover, as discussed in Section 7.1. 917 While TLSA records using a TLSA Selector of SPKI(1) and a TLSA 918 Matching Type of Full(0) (which publish the bare public keys without 919 the overhead of a containing X.509 certificate) are generally more 920 compact, these too should be used with caution as they are still 921 larger than necessary. Rather, servers SHOULD publish digest-based 922 TLSA Matching Types in their TLSA records. The complete 923 corresponding certificate should, instead, be transmitted to the 924 client in-band during the TLS handshake, which can be easily verified 925 using the digest value. 927 In summary, the use of a TLSA Matching Type of Full(0) is NOT 928 RECOMMENDED and the use of a digest-based matching type, such as 929 SHA2-256(1) SHOULD be used. 931 9.2. Certificate Name Check Conventions 933 Certificates presented by a TLS server will generally contain a 934 subjectAltName (SAN) extension or a Common Name (CN) element within 935 the subject distinguished name (DN). The TLS server's DNS domain 936 name is normally published within these elements, ideally within the 937 subjectAltName extension. (The use of the CN field for this purpose 938 is deprecated.) 940 When a server hosts multiple domains at the same transport endpoint, 941 the server's ability to respond with the right certificate chain is 942 predicated on correct SNI information from the client. DANE clients 943 MUST send the SNI extension with a HostName value of the base domain 944 of the TLSA RRset. 946 Except with TLSA Certificate Usage DANE-EE(3), where name checks are 947 not applicable (see Section 4.1), DANE clients MUST verify that the 948 client has reached the correct server by checking that the server 949 name is listed in the server certificate's SAN or CN. The server 950 name used for this comparison SHOULD be the base domain of the TLSA 951 RRset. Additional acceptable names may be specified by protocol- 952 specific DANE standards. For example, with SMTP both the destination 953 domain name and the MX host name are acceptable names to be found in 954 the server certificate (see [I-D.ietf-dane-smtp-with-dane]). 956 It is the responsibility of the service operator, in coordination 957 with the TLSA Publisher, to ensure that at least one of the TLSA 958 records published for the service will match the server's certificate 959 chain (either the default chain or the certificate that was selected 960 based on the SNI information provided by the client). 962 Given the DNSSEC validated DNS records below: 964 example.com. IN MX 0 mail.example.com. 965 mail.example.com. IN A 192.0.2.1 966 _25._tcp.mail.example.com. IN TLSA DANE-TA Cert SHA2-256 ( 967 E8B54E0B4BAA815B06D3462D65FBC7C0 968 CF556ECCF9F5303EBFBB77D022F834C0 ) 970 The TLSA base domain is "mail.example.com" and is required to be the 971 HostName in the client's SNI extension. The server certificate chain 972 is required to be be signed by a trust anchor with the above 973 certificate SHA2-256 digest. Finally, one of the DNS names in the 974 server certificate is required to be be either "mail.example.com" or 975 "example.com" (this additional name is a concession to compatibility 976 with prior practice, see [I-D.ietf-dane-smtp-with-dane] for details). 978 The semantics of wildcards in server certificates are left to 979 individual application protocol specifications. 981 9.3. Design Considerations for Protocols Using DANE 983 When a TLS client goes to the trouble of authenticating a certificate 984 chain presented by a TLS server, it will typically not continue to 985 use that server in the event of authentication failure, or else 986 authentication serves no purpose. Some clients may, at times, 987 operate in an "audit" mode, where authentication failure is reported 988 to the user or in logs as a potential problem, but the connection 989 proceeds despite the failure. Nevertheless servers publishing TLSA 990 records MUST be configured to allow correctly configured clients to 991 successfully authenticate their TLS certificate chains. 993 A service with DNSSEC-validated TLSA records implicitly promises TLS 994 support. When all the TLSA records for a service are found 995 "unusable", due to unsupported parameter combinations or malformed 996 associated data, DANE clients cannot authenticate the service 997 certificate chain. When authenticated TLS is dictated by the 998 application, the client SHOULD NOT connect to the associated server. 999 If, on the other hand, the use of TLS is "opportunistic", then the 1000 client SHOULD generally use the server via an unauthenticated TLS 1001 connection, but if TLS encryption cannot be established, the client 1002 MUST NOT use the server. Standards for DANE specific to the 1003 particular application protocol may modify the above requirements, as 1004 appropriate, to specify whether the connection should be established 1005 anyway without relying on TLS security, with only encryption but not 1006 authentication, or whether to refuse to connect entirely. 1007 Application protocols need to specify when to prioritize security 1008 over the ability to connect under adverse conditions. 1010 9.3.1. Design Considerations for non-PKIX Protocols 1012 For some application protocols (such as SMTP to MX with opportunistic 1013 TLS), the existing public CA PKI is not a viable alternative to DANE. 1014 For these (non-PKIX) protocols, new DANE standards SHOULD NOT suggest 1015 publishing TLSA records with TLSA Certificate Usage PKIX-TA(0) or 1016 PKIX-EE(1), as TLS clients cannot be expected to perform [RFC5280] 1017 PKIX validation or [RFC6125] identity verification. 1019 Protocols designed for non-PKIX use SHOULD choose to treat any TLSA 1020 records with TLSA Certificate Usage PKIX-TA(0) or PKIX-EE(1) as 1021 unusable. After verifying that the only available TLSA Certificate 1022 Usage types are PKIX-TA(0) or PKIX-EE(1), protocol specifications MAY 1023 instruct clients to either refuse to initiate a connection or to 1024 connect via unauthenticated TLS if no alternative authentication 1025 mechanisms are available. 1027 10. Interaction with Certificate Transparency 1029 Certificate Transparency (CT) [RFC6962] defines an experimental 1030 approach to mitigate the risk of rogue or compromised public CAs 1031 issuing unauthorized certificates. This section clarifies the 1032 interaction of CT and DANE. CT is an experimental protocol and 1033 auditing system that applies only to public CAs, and only when they 1034 are free to issue unauthorized certificates for a domain. If the CA 1035 is not a public CA, or a DANE-EE(3) TLSA RR directly specifies the 1036 end entity certificate, there is no role for CT, and clients need not 1037 apply CT checks. 1039 When a server is authenticated via a DANE TLSA RR with TLSA 1040 Certificate Usage DANE-EE(3), the domain owner has directly specified 1041 the certificate associated with the given service without reference 1042 to any PKIX certification authority. Therefore, when a TLS client 1043 authenticates the TLS server via a TLSA certificate association with 1044 usage DANE-EE(3), CT checks SHOULD NOT be performed. Publication of 1045 the server certificate or public key (digest) in a TLSA record in a 1046 DNSSEC signed zone by the domain owner assures the TLS client that 1047 the certificate is not an unauthorized certificate issued by a rogue 1048 CA without the domain owner's consent. 1050 When a server is authenticated via a DANE TLSA RR with TLSA usage 1051 DANE-TA(2) and the server certificate does not chain to a known 1052 public root CA, CT cannot apply (CT logs only accept chains that 1053 start with a known, public root). Since TLSA Certificate Usage DANE- 1054 TA(2) is generally intended to support non-PKIX trust anchors, TLS 1055 clients SHOULD NOT perform CT checks with usage DANE-TA(2) using 1056 unknown root CAs. 1058 A server operator who wants clients to perform CT checks should 1059 publish TLSA RRs with usage PKIX-TA(0) or PKIX-EE(1). 1061 11. Note on DNSSEC Security 1063 Clearly the security of the DANE TLSA PKI rests on the security of 1064 the underlying DNSSEC infrastructure. While this memo is not a guide 1065 to DNSSEC security, a few comments may be helpful to TLSA 1066 implementers. 1068 With the existing public CA PKI, name constraints are rarely used, 1069 and a public root CA can issue certificates for any domain of its 1070 choice. With DNSSEC, under the Registry/Registrar/Registrant model, 1071 the situation is different: only the registrar of record can update a 1072 domain's DS record in the registry parent zone (in some cases, 1073 however, the registry is the sole registrar). With many gTLDs, for 1074 which multiple registrars compete to provide domains in a single 1075 registry, it is important to make sure that rogue registrars cannot 1076 easily initiate an unauthorized domain transfer, and thus take over 1077 DNSSEC for the domain. DNS Operators SHOULD use a registrar lock of 1078 their domains to offer some protection against this possibility. 1080 When the registrar is also the DNS operator for the domain, one needs 1081 to consider whether the registrar will allow orderly migration of the 1082 domain to another registrar or DNS operator in a way that will 1083 maintain DNSSEC integrity. TLSA Publishers SHOULD ensure their 1084 registrar publishes a suitable domain transfer policy. 1086 DNSSEC signed RRsets cannot be securely revoked before they expire. 1087 Operators should plan accordingly and not generate signatures with 1088 excessively long duration periods. For domains publishing high-value 1089 keys, a signature lifetime of a few days is reasonable, and the zone 1090 should be resigned daily. For domains with less critical data, a 1091 reasonable signature lifetime is a couple of weeks to a month, and 1092 the zone should be resigned weekly. Monitoring of the signature 1093 lifetime is important. If the zone is not resigned in a timely 1094 manner, one risks a major outage and the entire domain will become 1095 bogus. 1097 12. Summary of Updates to RFC6698 1099 Authors note: is this section needed? Or is it sufficiently clear 1100 above that we don't need to restate things here? 1102 o In Section 3 we update [RFC6698] to specify a requirement for 1103 clients to support at least TLS 1.0, and to support SNI. 1105 o In Section 4.1 we update [RFC6698] to specify peer identity 1106 matching and certificate validity interval based solely on the 1107 basis of the TLSA RRset. We also specify DANE authentication of 1108 raw public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with 1109 Certificate Usage DANE-EE(3) and selector SPKI(1). 1111 o In Section 4.2 we update [RFC6698] to require that servers 1112 publishing digest TLSA records with a usage of DANE-TA(2) MUST 1113 include the trust-anchor certificate in their TLS server 1114 certificate message. This extends to the case of "2 1 0" TLSA 1115 records which publish a full public key. 1117 o In Section 4.3 and Section 4.4, we explain that PKIX-EE(1) and 1118 PKIX-TA(0) are generally NOT RECOMMENDED. With usage PKIX-TA(0) 1119 we note that clients may need to processes extended trust chains 1120 beyond the first trusted issuer, when that issuer is not self- 1121 signed. 1123 o In Section 6, we recommend that DANE application protocols specify 1124 that when possible securely CNAME expanded names be used to derive 1125 the TLSA base domain. 1127 o In Section 7, we specify a strategy for managing TLSA records that 1128 interoperates with DANE clients regardless of what subset of the 1129 possible TLSA record types (combinations of TLSA parameters) is 1130 supported by the client. 1132 o In Section 8, we propose a digest algorithm agility protocol. 1133 [Note: This section does not yet represent the rough consensus of 1134 the DANE working group and requires further discussion. Perhaps 1135 this belongs in a separate document.] 1137 o In Section 9.1 we recommend against the use of Full(0) TLSA 1138 records, as digest records are generally much more compact. 1140 13. Security Considerations 1142 Application protocols that cannot make use of the existing public CA 1143 PKI (so called non-PKIX protocols), may choose not to implement 1144 certain PKIX-dependent TLSA record types defined in [RFC6698]. If 1145 such records are published despite not being supported by the 1146 application protocol, they are treated as "unusable". When TLS is 1147 opportunistic, the client may proceed to use the server with 1148 mandatory unauthenticated TLS. This is stronger than opportunistic 1149 TLS without DANE, since in that case the client may also proceed with 1150 a plaintext connection. When TLS is not opportunistic, the client 1151 MUST NOT connect to the server. 1153 Therefore, when TLSA records are used with protocols where PKIX does 1154 not apply, the recommended policy is for servers to not publish PKIX- 1155 dependent TLSA records, and for opportunistic TLS clients to use them 1156 to enforce the use of (albeit unauthenticated) TLS, but otherwise 1157 treat them as unusable. Of course, when PKIX validation is supported 1158 by the application protocol, clients SHOULD perform PKIX validation 1159 per [RFC6698]. 1161 14. IANA Considerations 1163 This specification requires no support from IANA. 1165 15. Acknowledgements 1167 The authors would like to thank Phil Pennock for his comments and 1168 advice on this document. 1170 Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded 1171 me into participating in DANE working group discussions. Thanks to 1172 Paul Hoffman who motivated me to produce this memo and provided 1173 feedback on early drafts. Thanks also to Samuel Dukhovni for 1174 editorial assistance. 1176 16. References 1178 16.1. Normative References 1180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1181 Requirement Levels", BCP 14, RFC 2119, March 1997. 1183 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1184 Rose, "DNS Security Introduction and Requirements", RFC 1185 4033, March 2005. 1187 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1188 Rose, "Resource Records for the DNS Security Extensions", 1189 RFC 4034, March 2005. 1191 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1192 Rose, "Protocol Modifications for the DNS Security 1193 Extensions", RFC 4035, March 2005. 1195 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1196 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1198 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1199 Housley, R., and W. Polk, "Internet X.509 Public Key 1200 Infrastructure Certificate and Certificate Revocation List 1201 (CRL) Profile", RFC 5280, May 2008. 1203 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1204 Extension Definitions", RFC 6066, January 2011. 1206 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1207 Verification of Domain-Based Application Service Identity 1208 within Internet Public Key Infrastructure Using X.509 1209 (PKIX) Certificates in the Context of Transport Layer 1210 Security (TLS)", RFC 6125, March 2011. 1212 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1213 Security Version 1.2", RFC 6347, January 2012. 1215 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1216 of Named Entities (DANE) Transport Layer Security (TLS) 1217 Protocol: TLSA", RFC 6698, August 2012. 1219 16.2. Informative References 1221 [I-D.ietf-dane-registry-acronyms] 1222 Gudmundsson, O., "Adding acronyms to simplify DANE 1223 conversations", draft-ietf-dane-registry-acronyms-03 (work 1224 in progress), January 2014. 1226 [I-D.ietf-dane-smtp-with-dane] 1227 Dukhovni, V. and W. Hardaker, "SMTP security via 1228 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-06 1229 (work in progress), February 2014. 1231 [I-D.ietf-dane-srv] 1232 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 1233 Based Authentication of Named Entities (DANE) TLSA records 1234 with SRV and MX records.", draft-ietf-dane-srv-05 (work in 1235 progress), February 2014. 1237 [I-D.ietf-tls-oob-pubkey] 1238 Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 1239 T. Kivinen, "Using Raw Public Keys in Transport Layer 1240 Security (TLS) and Datagram Transport Layer Security 1241 (DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress), 1242 January 2014. 1244 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1245 Transparency", RFC 6962, June 2013. 1247 Authors' Addresses 1249 Viktor Dukhovni 1250 Unaffiliated 1252 Email: ietf-dane@dukhovni.org 1254 Wes Hardaker 1255 Parsons 1256 P.O. Box 382 1257 Davis, CA 95617 1258 US 1260 Email: ietf@hardakers.net