idnits 2.17.1 draft-ietf-dane-ops-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: Best Current Practice W. Hardaker 5 Expires: August 18, 2014 Parsons 6 February 14, 2014 8 DANE TLSA implementation and operational guidance 9 draft-ietf-dane-ops-03 11 Abstract 13 This memo provides guidance to server operators to help ensure that 14 clients will be able to authenticate a server's certificate chain via 15 published TLSA records. Guidance is also provided to clients for 16 selecting reliable TLSA record parameters and using them for server 17 authentication. Finally, guidance is given to protocol designers who 18 wish to make use of TLSA records when securing protocols using a 19 combination of the Transport Layer Security (TLS) protocol and TLSA 20 records. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 18, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. DANE TLSA record overview . . . . . . . . . . . . . . . . . . 4 59 2.1. Example TLSA record . . . . . . . . . . . . . . . . . . . 5 60 3. General DANE Guidelines . . . . . . . . . . . . . . . . . . . 6 61 3.1. TLS Requirements . . . . . . . . . . . . . . . . . . . . 6 62 3.2. DANE DNS Record Size Guidelines . . . . . . . . . . . . . 6 63 3.3. Certificate Name Check Conventions . . . . . . . . . . . 7 64 3.4. Service Provider and TLSA Publisher Synchronization . . . 8 65 3.5. TLSA Base Domain and CNAMEs . . . . . . . . . . . . . . . 10 66 3.6. Interaction with Certificate Transparency . . . . . . . . 11 67 3.7. Design Considerations for Protocols Using DANE . . . . . 11 68 3.8. TLSA Records and Trust Anchor Digests . . . . . . . . . . 12 69 3.9. Trust anchor public keys . . . . . . . . . . . . . . . . 13 70 4. Certificate Usage Specific DANE Guidelines . . . . . . . . . 14 71 4.1. Certificate Usage DANE-EE(3) Guidelines . . . . . . . . . 14 72 4.2. Certificate Usage DANE-TA(2) Guidelines . . . . . . . . . 15 73 4.3. Certificate Usage PKIX-EE(1) Guidelines . . . . . . . . . 15 74 4.4. Certificate Usage PKIX-TA(0) Guidelines . . . . . . . . . 15 75 5. Note on DNSSEC security . . . . . . . . . . . . . . . . . . . 16 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 81 9.2. Informative References . . . . . . . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 Section 2 of [RFC6698] specifies a new "TLSA" DNS resource record 87 which associates a TLS transport endpoint with a corresponding 88 trusted leaf or issuing authority certificates or public keys. 89 DNSSEC-validated DANE TLSA records can be used to augment or replace 90 the trust model of the existing public Certificate Authority (CA) 91 Public Key Infrastructure (PKI). 93 [RFC6698] defines 24 combinations of TLSA record parameters. 94 Additional complexity arises when the TLS transport endpoint is 95 obtained indirectly via a Service Record (SRV), Mail Exchange (MX) 96 record, CNAME records or other mechanisms that map an abstract 97 service domain to a concrete server domain. With service indirection 98 there are multiple potential places for clients to find the relevant 99 TLSA records. Service indirection is often used to implement 100 "virtual hosting", where a single Service Provider transport endpoint 101 simultaneously supports multiple hosted domain names. With services 102 that employ TLS, such hosting arrangements may require the Service 103 Provider to employ multiple pairs of private keys and certificates 104 with TLS clients signalling the desired domain via an Server Name 105 Indication (SNI) extension ([RFC6066], section 3). This memo 106 provides operational guidelines intended to maximize interoperability 107 between DANE TLS clients and servers. 109 In the context of this memo, channel security is assumed to be 110 provided by TLS or DTLS. The Transport Layer Security (TLS) 111 [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347] 112 protocols provide secured TCP and UDP communication over the IP. By 113 convention, "TLS" will be used throughout this document and, unless 114 otherwise specified, the text applies equally well to the DTLS 115 protocol. Used without authentication, TLS provides protection only 116 against eavesdropping through its use of encryption. With 117 authentication, TLS also provides integrity protection and 118 authentication, which protects the transport against man-in-the- 119 middle (MITM) attacks. 121 1.1. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 [RFC2119]. 128 The following terms are used throughout this document: 130 Service Provider: A company or organization that offers to host a 131 service on behalf of a Customer Domain. The original domain name 132 associated with the service often remains under the control of the 133 customer. Connecting applications may directed to the Service 134 Provider via a redirection resource record. Example redirection 135 records include MX, SRV, and CNAME. The Service Provider 136 frequently provides services for many customers and must carefully 137 manage any TLS credentials offered to connecting applications to 138 ensure name matching is handled easily by the applications. 140 Customer Domain: Customers that make use of a Service Provider to 141 outsource their service(s) will be referred to as "Customer 142 Domains". 144 TLSA Publisher: The entity responsible for publishing a TLSA record 145 within a DNS zone. This zone will be considered DNSSEC-signed and 146 validatable to a trust anchor, unless otherwise specified. If the 147 Customer Domain is not outsourcing their DNS service, the TLSA 148 Publisher will be the customer themselves. Otherwise the TLSA 149 Publisher may be the operator of the outsourced DNS service. 151 public key: The term "public key" will be an informal short-hand for 152 the subjectPublicKeyInfo component of a PKIX [RFC5280] 153 certificate. 155 SNI: "Server Name Indication", or SNI, describes the TLS protocol 156 extension by which a TLS client requests to connect to a 157 particular service name of a TLS server ([RFC6066], section 3). 158 Without this TLS extension, a TLS server has no choice but to 159 offer a PKIX certificate with a default list of server names, 160 making it difficult to host multiple Customer Domains at the same 161 TLS service endpoint (i.e., "secure virtual hosting"). 163 2. DANE TLSA record overview 165 DANE TLSA [RFC6698] specifies a protocol for publishing TLS server 166 certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035]. 167 The DANE TLSA specification defines multiple TLSA RR types via 168 combinations of 3 numeric parameters. The numeric values of these 169 parameters were later given symbolic names in 170 [I-D.ietf-dane-registry-acronyms]. These parameters are: 172 The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698] 173 specifies 4 values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE- 174 EE(3). There is an additional private-use value: PrivCert(255). 175 All other values are reserved for use by future specifications. 177 The selector field: Section 2.1.2 of [RFC6698] specifies 2 values: 178 Cert(0), SPKI(1). There is an additional private-use value: 179 PrivSel(255). All other values are reserved for use by future 180 specifications. 182 The matching type field: Section 2.1.3 of [RFC6698] specifies 3 183 values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional 184 private-use value: PrivMatch(255). All other values are reserved 185 for use by future specifications. 187 We may think of TLSA Certificate Usage values 0 through 3 as a 188 combination of two one-bit flags. The low-bit chooses between trust 189 anchor (TA) and end entity (EE) certificates. The high bit chooses 190 between PKIX, or public PKI issued, and TA, or domain-issued trust 191 anchors: 193 o When the low bit is set (PKIX-EE(1) and DANE-EE(3)) the TLSA 194 record matches an EE certificate (also commonly referred to as a 195 leaf or server certificate.) 197 o When the low bit is not set (PKIX-TA(0) and DANE-TA(2)) the TLSA 198 record matches a trust anchor (a Certificate Authority) that 199 issued one of the certificates in the server certificate chain. 201 o When the high bit is set (DANE-TA(2) and DANE-EE(3)), the server 202 certificate chain is domain-issued and may be verified without 203 reference to any pre-existing public certificate authority PKI. 204 Trust is entirely placed on the content of the TLSA records 205 obtained via DNSSEC. 207 o When the high bit is not set (PKIX-TA(0) and PKIX-EE(1)), the TLSA 208 record publishes a server policy stating that its certificate 209 chain must pass PKIX validation [RFC5280] and the DANE TLSA record 210 is used to constrain the server certificate chain to contain the 211 referenced CA or EE certificate. 213 The selector field specifies whether the TLSA RR matches the whole 214 certificate (Cert(0)) or just its subjectPublicKeyInfo (SPKI(1)). 215 The subjectPublicKeyInfo is an ASN.1 DER encoding of the 216 certificate's algorithm id, any parameters and the public key data. 218 The matching type field specifies how the TLSA RR Certificate 219 Association Data field is to be compared with the certificate or 220 public key. A value of Full(0) means an exact match: the full DER 221 encoding of the certificate or public key is given in the TLSA RR. A 222 value of SHA2-256(1) means that the association data matches the 223 SHA2-256 digest of the certificate or public key, and likewise 224 SHA2-512(2) means a SHA2-512 digest is used. Of the two digest 225 algorithms, for now only SHA2-256(1) is mandatory to implement. 226 Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT 227 exclusively publish SHA2-512(2) digests. A digest algorithm agility 228 protocol is proposed in section 2.3.3 of 229 [I-D.ietf-dane-smtp-with-dane] that SHOULD be used by clients to 230 decide how to process TLSA RRsets that employ multiple digest 231 algorithms. Server operators MUST publish TLSA RRsets that are 232 compatible with digest algorithm agility. 234 2.1. Example TLSA record 236 In the example TLSA record below: 238 _25._tcp.mail.example.com. 300 IN TLSA PKIX-TA Cert SHA2-256 ( 239 E8B54E0B4BAA815B06D3462D65FBC7C0 240 CF556ECCF9F5303EBFBB77D022F834C0 ) 242 The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and 243 the matching type is SHA2-256(1). The rest of the record is the 244 certificate association data field, which is in this case the 245 SHA2-256 digest of the server certificate. 247 3. General DANE Guidelines 249 These guidelines provide guidance for using or designing protocols 250 for DANE, regardless of what sort of TLSA record will be used. 252 3.1. TLS Requirements 254 TLS clients that support DANE/TLSA MUST support at least TLS 1.0 and 255 SHOULD support TLS 1.2. TLS clients and servers using DANE SHOULD 256 support the "Server Name Indication" extension of TLS. 258 3.2. DANE DNS Record Size Guidelines 260 Selecting a combination of TLSA parameters to use requires careful 261 thought. One important consideration to take into account is the 262 size of the resulting TLSA record after its parameters are selected. 264 3.2.1. UDP and TCP Considerations 266 Deployments SHOULD avoid TLSA record sizes that cause UDP 267 fragmentation. 269 Although DNS over TCP would provide the ability to transfer larger 270 DNS records between clients and servers, it is not universally 271 deployed and is still blocked by some firewalls. Clients that 272 request DNS records via UDP typically only use TCP upon receipt of a 273 truncated response in TCP. 275 3.2.2. Packet Size Considerations for TLSA Parameters 277 Server operators SHOULD NOT publish TLSA records using both a TLSA 278 Selector of Cert(0) and a TLSA Matching Type of Full(0), as even a 279 single certificate is generally too large to be reliably delivered 280 via DNS over UDP. Furthermore, two TLSA records containing full 281 certificates may need to be published simultaneously during a 282 certificate rollover. 284 While TLSA records using a TLSA Selector of SPKI(1) and a TLSA 285 Matching Type of Full(0) (which publishes the bare public key without 286 the overhead of a containing X.509 certificate) are generally more 287 compact, these too should be used with caution as they are still 288 larger than necessary. Rather, servers SHOULD publish digest-based 289 TLSA Matching Types in their TLSA records. The complete 290 corresponding certificate should, instead, be transmitted to the 291 client in-band during the TLS handshake. 293 In summary, the use of a TLSA Matching Type of Full(0) is NOT 294 RECOMMENDED and the use of SHA2-256(1) and SHA2-512(2) is strongly 295 preferred. 297 3.3. Certificate Name Check Conventions 299 Certificates presented by a TLS server will generally contain a 300 subjectAltName (SAN) extension or a Common Name (CN) element in the 301 subject distinguished name (DN). The server's DNS domain name should 302 be published within these elements, ideally within the subjectAltName 303 extension as use of the CN field for this purpose is deprecated. 304 Name checks SHOULD NOT consider the subject CN when SAN values of 305 type 'dns' are present. 307 When a server hosts multiple domains at the same transport endpoint, 308 the server's ability to respond with the right certificate chain is 309 predicated on correct SNI information from the client. DANE clients 310 MUST send the SNI extension with a HostName value of the base domain 311 of the TLSA RRset. 313 Except with TLSA Certificate Usage DANE-EE(3), where name checks are 314 not applicable (see Section 4.1), DANE clients MUST verify that the 315 client has reached the correct server by checking that the server 316 name is listed in the server certificate. The server name used for 317 this comparison SHOULD be the base domain of the TLSA RRset. 318 Additional acceptable names may be specified by protocol-specific 319 DANE standards. For example, with SMTP both the destination domain 320 name and the MX host name are acceptable names to be found in the 321 server certificate (see [I-D.ietf-dane-smtp-with-dane]). 323 It is the responsibility of the service operator, in coordination 324 with the TLSA Publisher, to ensure that at least one of the TLSA 325 records published for the service will match the server's certificate 326 chain (either the default chain or the certificate that was selected 327 based on the SNI information from the client). With certificate 328 usage values other than DANE-EE(3), the EE certificate SHOULD include 329 the TLSA base domain as one of its names. If other acceptable names 330 are specified by a protocol-specific DANE standard, one of those MAY 331 be used in place of the TLSA base domain. 333 Given the DNSSEC validated DNS records below: 335 example.com. 300 IN MX 0 mail.example.com. 336 _25._tcp.mail.example.com. 300 IN TLSA DANE-TA Cert SHA2-256 ( 337 E8B54E0B4BAA815B06D3462D65FBC7C0 338 CF556ECCF9F5303EBFBB77D022F834C0 ) 340 The TLSA base domain is "mail.example.com" and this MUST be the 341 HostName in the client's SNI extension. The server certificate chain 342 MUST be signed by a trust anchor with the above certificate SHA2-256 343 digest. One of the DNS names in the server certificate MUST be 344 either "mail.example.com" or "example.com". 346 3.4. Service Provider and TLSA Publisher Synchronization 348 Complications arise when the TLSA Publisher is not the same entity as 349 the Service Provider. In this situation, the TLSA Publisher and the 350 Service Provider must cooperate to ensure that TLSA records published 351 by the TLSA Publisher don't fall out of sync with the server 352 certificate used by the Service Provider. 354 Whenever possible, the TLSA Publisher and the Service Provider should 355 be the same entity. Otherwise, changes in the service certificate 356 chain must be carefully coordinated between the parties involved. 357 Such coordination is difficult and service outages will result when 358 coordination fails. 360 Having the master TLSA record in the Service Provider's zone avoids 361 the complexity of bilateral coordination of server certificate 362 configuration and TLSA record management. Even when the TLSA RRset 363 must be published in the Customer Domain's DNS zone, it is possible 364 to employ CNAME records (see Section 3.5) to delegate the content of 365 the TLSA RRset to a domain operated by the Service Provider. 366 Certificate name checks generally constrain the applicability of TLSA 367 CNAMEs across organizational boundaries to Certificate Usages DANE- 368 EE(3) and DANE-TA(2): 370 Certificate Usage DANE-EE(3): In this case the Service Provider can 371 publish a single TLSA RRset that matches the server certificate or 372 public key digest. The same RRset works for all Customer Domains 373 because name checks do not apply with DANE-EE(3) TLSA records (see 374 Section 4.1). A Customer Domain can create a CNAME record 375 pointing to the TLSA RRset published by the Service Provider. 377 Certificate Usage DANE-TA(2): When the Service Provider operates a 378 private certificate authority, the Service Provider is free to 379 issue a certificate bearing any customer's domain name. Without 380 DANE, such a certificate would not pass trust verification, but 381 with DANE, the customer's TLSA RRset that is aliased to the 382 provider's TLSA RRset can delegate authority to the provider's CA 383 for the corresponding service. The Service Provider can generate 384 appropriate certificates for each customer and use SNI to select 385 the right certificate chain to present to each client. 387 Below are example DNS records that illustrate both of of the above 388 cases in the case of an HTTPS service whose clients all support DANE 389 TLS. 391 ; Hosted web service redirected via a CNAME alias. 392 ; Associated TLSA RRset redirected via a CNAME alias. 393 ; 394 ; Single certificate at provider works for all Customer Domains 395 ; 396 www1.example.com. 300 IN CNAME w3.example.net. 397 _443._tcp.www3.example.com. 300 IN CNAME _443._tcp.w3.example.net. 398 _443._tcp.w3.example.net. 300 IN TLSA DANE-EE SPKI SHA2-256 ( 399 8A9A70596E869BED72C69D97A8895DFA 400 D86F300A343FECEFF19E89C27C896BC9 ) 401 ; 402 ; CA at provider can issue certificates for each Customer Domain. 403 ; 404 www2.example.com. 300 IN CNAME w2.example.net. 405 _443._tcp.www2.example.com. 300 IN CNAME _443._tcp.w2.example.net. 406 _443._tcp.w2.example.net. 300 IN TLSA DANE-TA Cert SHA2-256 ( 407 C164B2C3F36D068D42A6138E446152F5 408 68615F28C69BD96A73E354CAC88ED00C ) 410 With protocols that support explicit transport redirection via DNS MX 411 records, SRV records, or other similar records, the TLSA base domain 412 is based on the redirected transport end-point, rather than the 413 origin domain. With SMTP for example, when email service is hosted 414 by a Service Provider, the Customer Domain's MX hostnames will point 415 at the Service Provider's SMTP hosts. When the Customer Domain's DNS 416 zone is signed, the MX hostnames can be securely used as the base 417 domains for TLSA records that are published and managed by the 418 Service Provider. For example: 420 ; Hosted SMTP service 421 ; 422 example.com. 300 IN MX 0 mx1.example.net. 423 example.com. 300 IN MX 0 mx2.example.net. 424 _25._tcp.mx1.example.net. 300 IN TLSA DANE-EE SPKI SHA2-256 ( 425 8A9A70596E869BED72C69D97A8895DFA 426 D86F300A343FECEFF19E89C27C896BC9 ) 427 _25._tcp.mx2.example.net. 300 IN TLSA DANE-EE SPKI SHA2-256 ( 428 C164B2C3F36D068D42A6138E446152F5 429 68615F28C69BD96A73E354CAC88ED00C ) 431 If redirection to the Service Provider's domain (via MX or SRV 432 records or any similar mechanism) is not possible, and aliasing of 433 the TLSA record is not an option, then more complex coordination 434 between the Customer Domain and Service Provider is required. Either 435 the Customer Domain periodically provides private keys and a 436 corresponding certificate chain to the Provider after making 437 appropriate changes in its TLSA records, or the Service Provider 438 periodically generates the keys and certificates and must wait for 439 matching TLSA records to be published by its Customer Domains before 440 deploying newly generated keys and certificate chains. 442 For further information about combining DANE and SRV, please see 443 [I-D.ietf-dane-srv]. 445 3.5. TLSA Base Domain and CNAMEs 447 When the protocol does not support service location indirection via 448 MX, SRV or similar DNS records, the service may be redirected via a 449 CNAME. A CNAME is a more blunt instrument for this purpose, since 450 unlike an MX or SRV record, it remaps the origin domain to the target 451 domain for all protocols. 453 The complexity of coordinating key rollover is largely eliminated 454 when DANE TLSA records are found in the Service Provider's domain, as 455 discussed in Section 3.4. Therefore, DANE TLS clients connecting to 456 a server whose domain name is a CNAME alias SHOULD follow the CNAME 457 hop-by-hop to its ultimate target host (noting at each step whether 458 the CNAME is DNSSEC-validated). If at each stage of CNAME expansion 459 the DNSSEC validation status is "secure", the final target name 460 SHOULD be the preferred base domain for TLSA lookups. 462 Implementations failing to find a TLSA record using a base name of 463 the final target of a CNAME expansion SHOULD issue a TLSA query using 464 the original destination name. That is, the preferred TLSA base 465 domain should be derived from the fully expanded name, and failing 466 that should be the initial domain name. 468 Protocol-specific TLSA specifications may provide additional guidance 469 or restrictions when following CNAME expansions. 471 Though CNAMEs are illegal on the right hand side of most indirection 472 records, such as MX and SRV records, they are supported by some 473 implementations. For example, if the MX or SRV host is a CNAME 474 alias, some implementations may "chase" the CNAME. They SHOULD use 475 the target hostname as the preferred TLSA base domain as well as the 476 HostName in SNI, provided the CNAME RR is found to be "secure" at 477 each step in the CNAME expansion. 479 3.6. Interaction with Certificate Transparency 481 Certificate Transparency (CT) [RFC6962] defines an experimental 482 approach to mitigate the risk of rogue or compromised public CAs 483 issuing unauthorized certificates. This section clarifies the 484 interaction of CT and DANE. CT is an experimental protocol and 485 auditing system that applies only to public CAs, and only when they 486 are free to issue unauthorized certificates for a domain. If the CA 487 is not a public CA, or a DANE-EE(3) TLSA RR directly specifies the 488 end entity certificate, there is no role for CT, and clients need not 489 apply CT checks. 491 When a server is authenticated via a DANE TLSA RR with TLSA 492 Certificate Usage DANE-EE(3), the domain owner has directly specified 493 the certificate associated with the given service without reference 494 to any PKIX certificate authority. Therefore, when a TLS client 495 authenticates the TLS server via a TLSA certificate association with 496 usage DANE-EE(3), CT checks SHOULD NOT be performed. Publication of 497 the server certificate or public key (digest) in a TLSA record in a 498 DNSSEC signed zone by the domain owner assures the TLS client that 499 the certificate is not an unauthorized certificate issued by a rogue 500 CA without the domain owner's consent. 502 When a server is authenticated via a DANE TLSA RR with TLSA usage 503 DANE-TA(2) and the server certificate does not chain to a known 504 public root CA, CT cannot apply (CT logs only accept chains that 505 start with a known, public root). Since TLSA Certificate Usage DANE- 506 TA(2) is generally intended to support non-PKIX trust anchors, TLS 507 clients SHOULD NOT perform CT checks with usage DANE-TA(2) using 508 unknown root CAs. 510 A server operator who wants clients to perform CT checks should 511 publish TLSA RRs with usage PKIX-TA(0) or PKIX-EE(1). 513 3.7. Design Considerations for Protocols Using DANE 515 When a TLS client goes to the trouble of authenticating a certificate 516 chain presented by a TLS server, it should not continue to use that 517 server in the event of authentication failure, or else authentication 518 serves no purpose. Servers publishing TLSA records MUST be 519 configured to allow correctly configured clients to successfully 520 authenticate their TLS certificate chains. 522 A service with DNSSEC-validated TLSA records implicitly promises TLS 523 support. When all the TLSA records for a service are found 524 "unusable", due to unsupported parameter combinations or malformed 525 associated data, DANE clients cannot authenticate the service 526 certificate chain. When authenticated TLS is dictated by the 527 application, the client SHOULD NOT connect to the associated server. 528 If, on the other hand, the use of TLS is "opportunistic", then the 529 client SHOULD generally use the server via an unauthenticated TLS 530 connection, but if TLS encryption cannot be established, the client 531 MUST NOT use the server. Standards for DANE specific to the 532 particular application protocol may modify the above as appropriate 533 to specify whether the connection should be established anyway 534 without relying on TLS security, with only encryption but not 535 authentication, or whether to refuse to connect entirely. Protocols 536 must choose whether to prioritize security or robustness. 538 3.7.1. Design Considerations for non-PKIX Protocols 540 For some application protocols (such as SMTP to MX with opportunistic 541 TLS), the existing public CA PKI is not a viable alternative to DANE. 542 For these (non-PKIX) protocols, new DANE standards SHOULD NOT suggest 543 publishing TLSA records with TLSA Certificate Usage PKIX-TA(0) or 544 PKIX-EE(1), as TLS clients cannot be expected to perform [RFC5280] 545 PKIX validation or [RFC6125] identity verification. 547 Protocols designed for non-PKIX use SHOULD choose to treat any TLSA 548 records with TLSA Certificate Usage PKIX-TA(0) or PKIX-EE(1) as 549 unusable. After verifying that the only available TLSA Certificate 550 Usage types are PKIX-TA(0) or PKIX-EE(1), protocol specifications MAY 551 instruct clients to either refuse to initiate a connection or to 552 connect via unauthenticated TLS if no alternative authentication 553 mechanisms are available. 555 3.8. TLSA Records and Trust Anchor Digests 557 With TLSA records that match the EE certificate (i.e., DANE-EE(3) or 558 PKIX-EE(1)), the TLS client has no difficulty matching TLSA records 559 against the server certificate, as this certificate is always present 560 in the TLS server certificate chain. 562 With DANE TLSA records that match the digest of a TA certificate or 563 public key (i.e., DANE-TA(2) or PKIX-TA(0)), a complication arises 564 when the TA certificate is omitted from the server's certificate 565 chain. This can happen when the trust anchor is a root certificate 566 authority, as stated in section 7.4.2 of [RFC5246]: 568 The sender's certificate MUST come first in the list. Each 569 following certificate MUST directly certify the one preceding 570 it. Because certificate validation requires that root keys be 571 distributed independently, the self-signed certificate that 572 specifies the root certificate authority MAY be omitted from the 573 chain, under the assumption that the remote end must already 574 possess it in order to validate it in any case. 576 This means that TLSA records that match a TA certificate or public 577 key digest are not entirely sufficient to validate the peer 578 certificate chain. If no matching certificate is found in the 579 server's certificate chain, the chain may be signed by an omitted 580 root CA whose digest matches the TLSA record. With Certificate Usage 581 PKIX-TA(0), this is not a problem, since the client is expected to be 582 pre-configured with the issuing TA certificate. 584 With TLSA Certificate Usage DANE-TA(2), however, there is no 585 expectation that the client is pre-configured with the trust anchor 586 certificate. Rather, with TLSA Certificate Usage DANE-TA(2) clients 587 must be able to rely on the TLSA records alone. But, with a digest 588 in the TLSA record, the TLSA record contains neither the full trust 589 anchor certificate nor the full public key. If the TLS server's 590 certificate chain does not contain the trust anchor certificate, DANE 591 clients will be unable to authenticate the server. 593 TLSA Publishers that publish TLSA Certificate Usage DANE-TA(2) with a 594 digest (not Full(0)) matching type MUST ensure that the corresponding 595 server is configured to also include the trust anchor certificate in 596 its TLS handshake certificate chain, even if that certificate is a 597 self-signed root CA and would have been optional in the context of 598 the existing public CA PKI. 600 3.9. Trust anchor public keys 602 TLSA records with TLSA Certificate Usage DANE-TA(2), selector SPKI(1) 603 and a matching type of Full(0) publish the full public key of a trust 604 anchor via DNS. In section 6.1.1 of [RFC5280] the definition of a 605 trust anchor consists of the following four parts: 607 1. the trusted issuer name, 609 2. the trusted public key algorithm, 611 3. the trusted public key, and 613 4. optionally, the trusted public key parameters associated with the 614 public key. 616 Items 2-4 are precisely the contents of the subjectPublicKeyInfo 617 published in the TLSA record, but the issuer name is not included in 618 the public key. 620 With TLSA Certificate Usage DANE-TA(2), the client may not have the 621 associated trust anchor certificate, and cannot generally verify 622 whether a particular certificate chain is "issued by" the trust 623 anchor described in the TLSA record. If the server certificate chain 624 includes a CA certificate whose public key matches the TLSA record, 625 the client can match that CA as the intended issuer. Otherwise, the 626 client can only check that the topmost certificate in the server's 627 chain is "signed by" the trust anchor public key in the TLSA record. 629 Since trust chain validation via bare public keys rather than trusted 630 CA certificates may be difficult to implement using existing TLS 631 libraries, servers SHOULD include the trust anchor certificate in 632 their certificate chains when the TLSA Certificate Usage is DANE- 633 TA(2). 635 If none of the server's certificate chain elements match a public key 636 specified in full in a TLSA record, clients SHOULD check whether the 637 topmost certificate in the chain is signed by the provided public key 638 and has not expired, and if that is the case, and the rest of the 639 chain passes validation, consider the server authenticated if name 640 checks are also successful. 642 4. Certificate Usage Specific DANE Guidelines 644 4.1. Certificate Usage DANE-EE(3) Guidelines 646 Authentication via certificate usage "3" TLSA records involves simply 647 checking that the server's leaf certificate matches the TLSA record. 648 Other than extracting the relevant certificate elements for 649 comparison, no other use is made of the certificate content. 650 Authentication via certificate usage "3" TLSA records involves no 651 certificate authority signature checks. It also involves no server 652 name checks, and thus does not impose any new requirements on the 653 names contained in the server certificate (servers don't require an 654 SNI extension to be present when the TLSA record matches the server's 655 default certificate). 657 Two TLSA records will need to be published before updating a server's 658 public key, one matching the currently deployed key and the other 659 matching the new key scheduled to replace it. Once sufficient time 660 has elapsed for all the previous TLSA RRsets, which contains only the 661 old key, to expire from DNS caches, the server may be reconfigured to 662 use the new private key and associated certificate chain. Once the 663 server is using the new key, the TLSA RR that matches the retired key 664 can be removed from DNS, leaving only the TLSA RR that matches the 665 new key. 667 TLSA records for servers SHOULD, when possible, be DANE-EE(3), 668 SPKI(1), SHA2-256(1) records. Such records specify the SHA2-256 669 digest of the public key of the server certificate. Since all DANE 670 implementations are required to support SHA2-256, this record works 671 for all clients and need not change across certificate renewals with 672 the same key. With no name checks required, this TLSA record type 673 supports hosting arrangements with a single certificate matching all 674 client domains! It is also the easiest to implement correctly in the 675 client. 677 4.2. Certificate Usage DANE-TA(2) Guidelines 679 Some domains may prefer to reduce the operational complexity of 680 maintaining a distinct TLSA RRset for each TLS service. If the 681 domain employs a common issuing certificate authority to create 682 certificates for multiple TLS services, it may be simpler to publish 683 the issuing authority as a trust anchor (TA) for the certificate 684 chains of all relevant services. The TLSA RRs for each service 685 issued by the same TA may then be CNAMEs to a common TLSA RRset that 686 matches the TA. This certificate usage also allows Service Providers 687 to independently generate appropriate certificates for each Customer 688 Domain (see Section 3.4). 690 As explained in Section 3.8, servers that employ Certificate Usage 691 DANE-TA(2) TLSA records MUST include the TA certificate as part of 692 the certificate chain presented in the TLS handshake even when it is 693 a self-signed root certificate. TLSA Publishers should publish 694 either "DANE-TA(2) SPKI(1) SHA2-256(1)" or "DANE-TA(2) Cert(0) 695 SHA2-256(1)" TLSA parameters. As with leaf certificate rollover 696 discussed in Section 4.1, two such TLSA RRs need to be published to 697 facilitate TA certificate rollover. 699 4.3. Certificate Usage PKIX-EE(1) Guidelines 701 From a TLSA record perspective this certificate usage is similar to 702 DANE-EE(3), but in addition PKIX verification is required. 703 Therefore, name checks, certificate expiration, etc., apply as they 704 would without DANE. It should be noted that an attacker who can 705 compromise DNSSEC can replace these with usage DANE-EE(3) or DANE- 706 TA(2) TLSA records of his choosing, and thus bypass the PKIX 707 verification requirements. 709 Therefore, in most cases this certificate usage offers only illusory 710 incremental security over usage DANE-EE(3). It provides lower 711 operational reliability than usage 3 since when some clients may not 712 be configured with the required root CA, the server's chain may be 713 incomplete or name checks may fail. PKIX-EE(1) also requires more 714 complex coordination between the Customer Domain and the Service 715 Provider in hosting arrangements. This certificate usage is NOT 716 RECOMMENDED. 718 4.4. Certificate Usage PKIX-TA(0) Guidelines 719 TLSA Certificate Usage PKIX-TA(0) allows a domain to publish 720 constraints on the set of certificate authorities trusted to issue 721 certificates for its TLS servers. Clients MUST only accept PKIX- 722 verified trust chains which contain a match for one of the published 723 TLSA records. 725 TLSA Publishers MAY publish TLSA records for a particular public root 726 CA, expecting that clients will then only accept chains anchored at 727 that root. It is possible, however, that the client's trusted 728 certificate store includes some intermediate CAs, either with or 729 without the corresponding root CA. When a client constructs a trust 730 chain leading from a trusted intermediate CA to the server leaf 731 certificate, such a "truncated" chain might not contain a trusted 732 root published in the server's TLSA records. 734 If the omitted root is also trusted, the client may erroneously 735 reject the server chain if it fails to determine that the shorter 736 chain it constructed extends to a longer trusted chain that matches 737 the TLSA records. This means that, when matching a usage PKIX-TA(0) 738 TLSA record, a client SHOULD NOT always stop extending the chain when 739 the first locally trusted certificate is found. If no TLSA records 740 have matched any of the elements of the chain, it MUST attempt to 741 build a longer chain if the trusted certificate found is not self- 742 issued, in the hope that a certificate closer to the root may in fact 743 match the server's TLSA records. 745 As with PKIX-EE(1) case, An attacker who can compromise DNSSEC can 746 replace these with usage DANE-EE(3) or DANE-TA(2) TLSA records of his 747 choosing and thus bypass the PKIX verification requirements. 748 Therefore, in most cases this certificate usage offers only illusory 749 incremental security over usage DANE-TA(2). It provides lower 750 reliability than usage 2, though, since some clients may not be 751 configured with the required root CA, and additionally requires more 752 complex coordination between the Customer Domain and the Service 753 Provider in hosting arrangements. This certificate usage is NOT 754 RECOMMENDED. 756 5. Note on DNSSEC security 758 Clearly the security of the DANE TLSA PKI rests on the security of 759 the underlying DNSSEC infrastructure. While this memo is not a guide 760 to DNSSEC security, a few comments may be helpful to TLSA 761 implementors. 763 With the existing public CA PKI, name constraints are rarely used, 764 and a public root CA can issue certificates for any domain of its 765 choice. With DNSSEC, the situation is different. Only the registrar 766 of record can update a domain's DS record in the registry parent zone 767 (in some cases, however, the registry is the sole registrar). With 768 many gTLDs, for which multiple registrars compete to provide domains 769 in a single registry, it is important to make sure that rogue 770 registrars cannot easily initiate an unauthorized domain transfer, 771 and thus take over DNSSEC for the domain. DNS Operators SHOULD use a 772 registrar lock of their domains to offer some protection against this 773 possibility. 775 When the registrar is also the DNS operator for the domain, one needs 776 to consider whether the registrar will allow orderly migration of the 777 domain to another registrar or DNS operator in a way that will 778 maintain DNSSEC integrity. TLSA Publishers SHOULD ensure their 779 registrar publishes a suitable domain transfer policy. 781 DNSSEC signed RRsets cannot be securely revoked before they expire. 782 Operators should plan accordingly and not generate signatures with 783 excessively long duration. For domains publishing high-value keys, a 784 signature lifetime of a few days is reasonable, and the zone should 785 be resigned daily. For domains with less critical data, a reasonable 786 signature lifetime is a couple of weeks to a month, and the zone 787 should be resigned weekly. Monitoring of the signature lifetime is 788 important. If the zone is not resigned in a timely manner, one risks 789 a major outage with the entire domain becoming invalid. 791 6. Security Considerations 793 Application protocols that cannot make use of the existing public CA 794 PKI (so called non-PKIX protocols), may choose not to implement 795 certain PKIX-dependent TLSA record types defined in [RFC6698]. If 796 such records are published despite not being supported by the 797 application protocol, they are treated as "unusable". When TLS is 798 opportunistic, the client may proceed to use the server with 799 mandatory unauthenticated TLS. This is stronger than opportunistic 800 TLS without DANE, since in that case the client may also proceed with 801 a plaintext connection. When TLS is not opportunistic, the client 802 MUST NOT connect to the server. 804 Therefore, when TLSA records are used with protocols where PKIX does 805 not apply, the recommended policy is for servers to not publish PKIX- 806 dependent TLSA records, and for opportunistic TLS clients to use them 807 to enforce the use of (albeit unauthenticated) TLS, but otherwise 808 treat them as unusable. Of course, when PKIX validation is supported 809 by the application protocol, clients SHOULD perform PKIX validation 810 per [RFC6698]. 812 7. IANA considerations 814 This specification requires no support from IANA. 816 8. Acknowledgements 818 The authors would like to thank Phil Pennock for his comments and 819 advice on this document. 821 Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded 822 me into participating in DANE working group discussions. Thanks to 823 Paul Hoffman who motivated me to produce this memo and provided 824 feedback on early drafts. Thanks also to Samuel Dukhovni for 825 editorial assistance. 827 9. References 829 9.1. Normative References 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, March 1997. 834 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 835 Rose, "DNS Security Introduction and Requirements", RFC 836 4033, March 2005. 838 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 839 Rose, "Resource Records for the DNS Security Extensions", 840 RFC 4034, March 2005. 842 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 843 Rose, "Protocol Modifications for the DNS Security 844 Extensions", RFC 4035, March 2005. 846 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 847 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 849 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 850 Housley, R., and W. Polk, "Internet X.509 Public Key 851 Infrastructure Certificate and Certificate Revocation List 852 (CRL) Profile", RFC 5280, May 2008. 854 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 855 Extension Definitions", RFC 6066, January 2011. 857 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 858 Verification of Domain-Based Application Service Identity 859 within Internet Public Key Infrastructure Using X.509 860 (PKIX) Certificates in the Context of Transport Layer 861 Security (TLS)", RFC 6125, March 2011. 863 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 864 Security Version 1.2", RFC 6347, January 2012. 866 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 867 of Named Entities (DANE) Transport Layer Security (TLS) 868 Protocol: TLSA", RFC 6698, August 2012. 870 9.2. Informative References 872 [I-D.ietf-dane-registry-acronyms] 873 Gudmundsson, O., "Adding acronyms to simplify DANE 874 conversations", draft-ietf-dane-registry-acronyms-03 (work 875 in progress), January 2014. 877 [I-D.ietf-dane-smtp-with-dane] 878 Dukhovni, V. and W. Hardaker, "SMTP security via 879 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-06 880 (work in progress), February 2014. 882 [I-D.ietf-dane-srv] 883 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 884 Based Authentication of Named Entities (DANE) TLSA records 885 with SRV and MX records.", draft-ietf-dane-srv-05 (work in 886 progress), February 2014. 888 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 889 Transparency", RFC 6962, June 2013. 891 Authors' Addresses 893 Viktor Dukhovni 894 Unaffiliated 896 Email: ietf-dane@dukhovni.org 898 Wes Hardaker 899 Parsons 900 P.O. Box 382 901 Davis, CA 95617 902 US 904 Email: ietf@hardakers.net