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