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