idnits 2.17.1 draft-ietf-dane-ops-00.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the omitted root is also trusted, the client may erroneously reject the server chain if it fails to determine that the shorter chain it constructed extends to a longer trusted chain that matches the TLSA records. This means that a client SHOULD not always stop extending the chain when the first locally trusted certificate is found. If no TLSA records have matched any of the elements of the chain, it MUST attempt to build a longer chain if the trusted certificate found is not self-issued, in the hope that a certificate closer to the root may in fact match the server's TLSA records. -- The document date (October 08, 2013) is 3845 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 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3546 (Obsoleted by RFC 4366) ** 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 (-14) exists of draft-ietf-dane-srv-02 Summary: 8 errors (**), 0 flaws (~~), 3 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: April 11, 2014 Parsons 6 October 08, 2013 8 DANE TLSA implementation and operational guidance 9 draft-ietf-dane-ops-00 11 Abstract 13 This memo provides operational guidance to server operators to help 14 ensure that clients will be able to authenticate a server's 15 certificate chain via published TLSA records. Guidance is also 16 provided to clients for selecting reliable TLSA record parameters to 17 use for server authentication. Finally, guidance is given to 18 protocol designers who wish to make use of TLSA records to secure 19 protocols using a TLS and TLSA combination. 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 April 11, 2014. 38 Copyright Notice 40 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . 6 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 . . . 7 64 3.5. TLSA Base Domain and CNAMEs . . . . . . . . . . . . . . . 8 65 3.6. TLSA Base Name Priorities . . . . . . . . . . . . . . . . 9 66 3.7. Interaction with Certificate Transparency . . . . . . . . 9 67 3.8. Design Considerations for Protocols Using DANE . . . . . 10 68 3.9. TLSA Records and Trust Anchor Digests . . . . . . . . . . 12 69 3.10. Trust anchor public keys . . . . . . . . . . . . . . . . 13 70 4. Type Specific DANE Guidelines . . . . . . . . . . . . . . . . 14 71 4.1. Type 3 Guidelines . . . . . . . . . . . . . . . . . . . . 14 72 4.2. Type 2 Guidelines . . . . . . . . . . . . . . . . . . . . 14 73 4.3. Type 1 Guidelines . . . . . . . . . . . . . . . . . . . . 14 74 4.4. Type 0 Guidelines . . . . . . . . . . . . . . . . . . . . 14 75 5. Note on DNSSEC security . . . . . . . . . . . . . . . . . . . 15 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 80 8.2. Informative References . . . . . . . . . . . . . . . . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 The Domain Name System Security Extensions (DNSSEC) add data origin 86 authentication and data integrity to the Domain Name System. DNSSEC 87 is defined in [RFC4033], [RFC4034] and [RFC4035]. 89 In the context of this memo, channel security is assumed to be 90 provided by TLS or DTLS. The Transport Layer Security (TLS) and 91 Datagram Transport Layer Security (DTLS) protocols provide secured 92 TCP and UDP communication over the Internet Protocol. By convention, 93 "TLS" will be used through this document and, unless otherwise 94 specified, the text applies equally as well to the DTLS protocol. 95 Used without authentication, TLS provides protection only against 96 eavesdropping. With authentication, TLS also provides protection 97 against man-in-the-middle (MITM) attacks. Since the publication of 98 the TLS 1.0 specification in [RFC2246], two updates to the protocol 99 have been published: TLS 1.1 [RFC4346] and TLS 1.2 [RFC5246]. The 100 DTLS protocol was later documented in [RFC6347]. 102 As described in the introduction of [RFC6698], TLS authentication via 103 the existing public Certificate Authority (CA) Public Key 104 Infrastructure (PKI) suffers from an over-abundance of trusted 105 certificate authorities capable of issuing certificates for any 106 domain of their choice. DNS-Based Authentication of Named Entities 107 (DANE) leverages the DNSSEC infrastructure to publish trusted keys 108 and certificates for use with TLS via a new TLSA record type. DNSSEC 109 validated DANE TLSA records have created a new PKI designed to 110 augment or replace the trust model of the existing public CA PKI. 112 When a TLS client goes to the trouble of authenticating a certificate 113 presented by a TLS server, it should not continue to use the server 114 in case of authentication failure or else authentication serves no 115 purpose. Consequently, if a client cannot reliably authenticate 116 correctly configured, legitimate servers via a particular combination 117 of TLSA parameters, then the client should treat that combination of 118 parameters as unusable. Otherwise, the client risks routinely 119 dropping connections to legitimate servers. Servers publishing TLSA 120 records MUST be configured to allow correctly configured clients to 121 successfully authenticate the server's TLS certificate. 123 If a TLSA record is found as unusable because of a parameter 124 combination, it is protocol specific as to whether the connection 125 should be established anyway without security, with only TLS 126 encryption and not authentication, or to refuse to connect entirely. 128 1.1. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 This memo is being discussed on the dane@ietf.org mailing list. 136 The following terms are used throughout this document: 138 Service Provider: A company or organization that offers to host a 139 service on behalf of a Client Domain. The original domain name 140 associated with the service is typically still within the control 141 of the client, however, and the service provider is frequently 142 referred to by a redirection resource record. Example redirection 143 records include MX, SRV, and CNAME. Many times the Service 144 Provider provides services for many customers and must carefully 145 manage TLS credentials offered to their clients to ensure name 146 matching is handled easily by clients. 148 Client Domain: Clients that make use of a Service Provider to 149 outsource their services will be referred to as "Client Domains". 151 TLSA Publisher: The entity responsible for publishing a TLSA record 152 within a DNS zone. This zone will be considered DNSSEC signed, 153 unless otherwise specified. If the Client Domain is not 154 outsourcing their DNS service, the TLSA Publisher will be the 155 client themselves. Otherwise the TLSA Publisher may be the 156 outsourced DNS service instead. 158 public key: The term "public key" will be an informal short-hand for 159 the subjectPublicKeyInfo from a PKIX certificate. 161 SNI: The "Server Name Indication", or SNI, describes the process by 162 which a TLS client requests to connect to a particular service 163 name for a TLS server ([RFC3546]). Without this TLS extension, a 164 TLS server has no choice but to offer a PKIX certificate with a 165 default server name. Service Providers that are expected to host 166 services for many clients need to present the correct certificate 167 for the correct client, and the SNI extension provides a hint to 168 the server which certificate should be transmitted to the client. 170 2. DANE TLSA record overview 172 [RFC6698] specifies a protocol for publishing TLS server certificate 173 associations via DNSSEC. The DANE TLSA specification defines 174 multiple TLSA RR types via combinations of the following 3 175 parameters: 177 o The TLSA Certificate Usage field. Section 2.1.1 of [RFC6698] 178 specifies 4 values ranging from 0 to 3. 180 o The selector field. Section 2.1.2 of [RFC6698] specifies 2 values 181 ranging from 0 to 1. 183 o The matching type field. Section 2.1.3 of [RFC6698] specifies 3 184 values ranging from 0 to 2. 186 We may consider the TLSA Certificate Usage values 0 through 3 to be a 187 combination of two one-bit flags. The low-bit chooses between 188 referencing trust-anchor (TA) and end-entity (EE) certificates. The 189 high bit chooses between public PKI issued and domain-issued 190 certificates: 192 o When the low bit is set (TLSA Certificate Usages 1 and 3) the TLSA 193 record matches an EE (server) certificate. 195 o When the low bit is not set (TLSA Certificate Usages 0 and 2) the 196 TLSA record matches a trust-anchor (a certificate authority) that 197 issued a certificate somewhere in the certificate chain that 198 authenticates the final end-entity certificate. 200 o When the high bit is set (TLSA Certificate Usages 2 and 3) the 201 server certificate chain is domain-issued and may be verified 202 without reference to the existing public certificate authority 203 PKI. Trust is entirely placed on the content of the TLSA records 204 obtained via DNSSEC. 206 o When the high bit is not set (TLSA Certificate Usages 0 and 1) the 207 TLSA record publishes a server policy stating that its certificate 208 chain must pass PKIX validation [RFC5280], with the DANE TLSA 209 record used to constrain the server certificate chain to contain 210 the referenced CA or EE certificate. 212 The selector field specifies whether the TLSA RR matches the whole 213 certificate or just its subjectPublicKeyInfo (i.e. an ASN.1 DER 214 encoding of the certificate's algorithm id, any parameters and the 215 public key data). A selector field of "0" specifies the whole 216 certificate. A selector field of "1" specifies just the public key. 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 "0" means exact match, the DER encoding of 221 the certificate or public key is given in the TLSA RR. A "1" value 222 means a SHA-256 digest and "2" means a SHA-512 digest. Of these, 223 only SHA-256 is mandatory to implement. Clients SHOULD implement 224 SHA-512, but servers SHOULD NOT exclusively publish SHA-512 digests. 225 Unless a "second preimage" attack is found against SHA-256, servers 226 should only publish SHA-256 digests. 228 2.1. Example TLSA record 230 In the example TLSA record below: 232 _25._tcp.mail.example.com. IN TLSA 3 0 1 ( 233 E8B54E0B4BAA815B06D3462D65FBC7C0 234 CF556ECCF9F5303EBFBB77D022F834C0 ) 236 The TLSA Certificate Usage is "3", the selector is "0" and the 237 matching type is "1". The rest of the record is the certificate 238 association data field, which is in this case the SHA-256 digest of 239 the server certificate. 241 3. General DANE Guidelines 243 These guidelines provide guidance for using or designing protocols 244 for DANE, regardless of what type the TLSA record will actually 245 contain. 247 3.1. TLS Requirements 249 TLS clients that support DANE/TLSA MUST support at least TLS 1.0 and 250 SHOULD support TLS 1.2. TLS clients and servers using DANE SHOULD 251 support the "Server Name Indication" extension of TLS. 253 3.2. DANE DNS Record Size Guidelines 255 Selecting a combination of TLSA parameters to use requires careful 256 thought. One important consideration is the size of the resulting 257 TLSA record based on the parameters chosen. 259 3.2.1. UDP and TCP Considerations 261 Deployments SHOULD avoid TLSA record sizes that cause UDP 262 fragmentation. 264 Although DNS over TCP would provide the ability to transfer larger 265 DNS records between clients and servers, it is not yet widely 266 deployed or permitted through many firewalls. TCP must be expected 267 to be deployed on all the DNS servers and DNS clients for it to be a 268 truly viable large-record solution. 270 3.2.2. Packet Size Considerations for TLSA Parameters 272 Server operators SHOULD NOT publish "TLSA * 0 0" records, as even a 273 single certificate is generally too large to be reliably delivered 274 via DNS without TCP being widely available. Furthermore, two full 275 certificates may need to be published in the TLSA RRset for 276 certificate rollover. 278 While "TLSA * 1 0" records, which publish full public keys without 279 the full X.509 wrapping, are generally more compact, these too should 280 be used with caution. Servers SHOULD publish digests within TLSA 281 records instead. The complete certificate should, instead, be 282 transmitted to the client in band during the TLS handshake. 284 3.3. Certificate Name Check Conventions 286 Certificates presented by a TLS server will contain either a Common 287 Name (CN) or subjectAltName (or both), according to [RFC5280]. The 288 server's hostname should be published within these fields, ideally 289 within the subjectAltName. This section discusses what must be done 290 to match an expected name against the name found within a 291 certificate, if required. 293 The TLSA Publisher for TLSA records for a given service MUST ensure 294 that at least one of these TLSA records will match the server's 295 certificate chain. If SNI is not employed for a TLS connection, the 296 TLSA record must match the server's default certificate. If the SNI 297 extension is sent by the client with a host_name (see [RFC3546] 298 Section 3.1) equal to the base domain of the TLSA RRset, at least one 299 TLSA record must match the certificate presented by the server for 300 that host_name. 302 When, for example, the TLSA RRset is published at 304 _25._tcp.mail.example.com 306 the TLSA base domain is mail.example.com. At least one of the TLSA 307 records in the _25._tcp.mail.example.com RRset MUST match the server 308 certificate chain, provided the client TLS hanshake included the SNI 309 extension with a host_name of "mail.example.com". 311 Note: Except with TLSA Certificate Usage "3", where name checks are 312 not applicable (see Section 4.1), DANE aware clients SHOULD use the 313 base domain of the TLSA RRset to verify that the client has reached 314 the correct server by checking that the TLSA base domain is matched 315 by one of the subjectAltName ([RFC5280]) in the server certificate. 316 The commonName from the certificate subject DN MAY be used only when 317 no subjectAltNames of type 'dns' are present. Additional acceptable 318 names may be specified by protocol specific DANE RFCs. For example, 319 with SMTP both the destination domain name and the MX host name are 320 acceptable in the server certificate. 322 Since the server's ability to respond with the right certificate 323 chain requires the TLS client to provide the correct SNI information, 324 DANE PKI aware clients SHOULD send the SNI extension with a host_name 325 value of the base domain of the TLSA RRset (otherwise they risk 326 failure to authenticate the server). 328 3.4. Service Provider and TLSA Publisher Synchronization 330 Complications arise when the TLSA Publisher is not the same entity as 331 the Service Provider. In this situation, the TLSA Publisher and the 332 Service Provider must cooperate to ensure that TLSA records don't 333 fall out of sync with the server certificate configuration. 335 Ideally, the TLSA Publisher and the Service Provider should be the 336 same entity. If a TLSA record must be published in the client's base 337 domain, CNAME records can be easily used to point at the real TLSA 338 record in the Service Provider's zone assuming certificate usage 3 339 TLSA records are published by the Service Provider (see Section 3.5). 340 Having the master TLSA record in the Service Provider's zone avoids 341 the complexity of bilateral coordination of server certificate 342 configuration and TLSA record management. 344 For example, with SMTP, the customer's MX records can be pointed at 345 the Service Provider's MX hosts. When the customer's DNS zone is 346 signed, the MX records can be securely used as the base names for 347 TLSA records managed by the Service Provider. 349 3.5. TLSA Base Domain and CNAMEs 351 When the protocol does not support service location indirection via 352 MX, SRV or similar DNS records, the service may be redirected via a 353 CNAME. A CNAME is a more blunt instrument for this purpose, since 354 unlike an MX or SRV record, it remaps the origin domain to the target 355 domain for all protocols. Also Unlike MX or SRV records, CNAME 356 records may chain (though clients will generally impose 357 implementation dependent maximum nesting depths). 359 When CNAMEs are employed, the best place to seek DANE TLSA records is 360 in the Service Provider's domain, as discussed in Section 3.4. 361 Therefore, DANE PKI clients connecting to a server whose domain name 362 is a CNAME alias SHOULD follow the CNAME hop-by-hop to its ultimate 363 target host (noting at each step whether the CNAME is DNSSEC 364 validated) and use the resulting target host as the base domain for 365 TLSA lookups. Standards defining how to use DANE anchored TLS for 366 each application protocol are expected to specify where to locate 367 TLSA RRs when the destination is referred to by a CNAME. 369 If CNAMEs were not followed, Client Domains would need to publish 370 TLSA records that match the Service Provider's certificate chain or 371 always use an entity that was both the Service Provider and the TLSA 372 publisher. Having the TLSA base domain be different than the Service 373 Provider's domain imposes a difficult key management burden on the 374 Client Domain and the Service Provider. 376 It is possible to publish CNAMEs in the Client Domain pointing to the 377 Service Provider's TLSA RRset if the TLSA certificate usage field is 378 set to 3. Otherwise, a client that used the alias name (from the 379 hosted domain rather than the Service Provider's domain) as the base 380 domain to obtain the TLSA RRset would look for the hosted domain in 381 the server certificate when performing name checks, and would 382 generally fail to authenticate the server except in the rare cases 383 when the server's certificate does include the Client Domain. SNI 384 SHOULD be used to help perform the right certificate selection by the 385 server, although this imposes a management burden on the TLS server 386 that could be avoided by ensuring the TLSA base domain is within the 387 Service Provider's control in the first place. 389 Example CNAME record for a TLSA domain: 391 ; TLSA RRs aliased to Service Provider, but the base domain is 392 ; the hosted domain. Likely to fail name check unless Service 393 ; Provider usage is "3". 394 ; 395 _25._tcp.mail.example.com. IN CNAME _25._tcp.mail.example.net. 396 _25._tcp.mail.example.net. IN TLSA 3 1 1 ... 398 Note: when the TLSA RRset query domain (base domain plus port and 399 protocol prefixes) resolves to a DNSSEC validated CNAME that points 400 to a DNSSEC signed zone with the actual TLSA records, as the above 401 example indicates, it has no effect on the value of the base domain, 402 which remains the original domain to which the client prefixed the 403 port and protocol. In the example above, the base domain is 404 "mail.example.com" and not "mail.example.net". 406 Though CNAMEs are illegal on the right hand side of most indirection 407 records, such as MX and SRV records, they are supported by some 408 implementations. In this case, if the MX or SRV host is a CNAME 409 alias the client MAY "chase" the CNAME and SHOULD use the target 410 hostname as the base domain for TLSA records as well as the host_name 411 in SNI, provided the CNAME RR is found to be "secure" at each step in 412 the CNAME expansion. 414 3.6. TLSA Base Name Priorities 416 There are multiple steps within a chaining DNS lookup process that 417 TLSA base names can be pulled from. This section will discuss what 418 the preferred selection points are. TBD. 420 1. Final Domain Name 422 2. Redirect Name 424 3. Initial Name 426 3.7. Interaction with Certificate Transparency 428 [RFC6962] Certificate Transparency or CT for short, defines an 429 approach to mitigate the risk of rogue or compromised public CAs 430 issuing unauthorized certificates. This section clarifies the 431 interaction of CT and DANE. CT is a protocol and auditing system 432 that applies only to public CAs, and only when they are free to issue 433 unauthorized certificates for a domain. If the CA is not a public 434 CA, or DANE TLSA RRs constrain the end-entity certificate to a fixed 435 public key, there is no role for CT, and clients SHOULD NOT apply CT 436 checks. 438 When a server is authenticated via a DANE TLSA RR with TLSA 439 Certificate Usage "1" or "3" (that is an end-entity certificate 440 association), the domain owner has unambiguously specified the 441 certificate associated with the given service. Even if a rogue CA 442 were able to issue an unauthorized end-entity certificate that binds 443 a public key to a name in that domain, barring "second preimage" 444 attacks on the hashing algorithms in use, any such certificate would 445 not match the TLSA record and would be rejected. Therefore, when a 446 TLS client authenticates the TLS server via a TLSA certificate 447 association with usage "1" or "3", CT checks SHOULD NOT be performed. 448 Publication of the server certificate or public key (digest) in a 449 DNSSEC signed zone by the domain owner assures the client that the 450 certificate is not an unauthorized certificate issued by a rogue CA 451 without the domain owner's consent. 453 When a server is authenticated via a DANE TLSA RR with TLSA usage "2" 454 and the server certificate does not chain to a known public root CA, 455 CT cannot apply (CT logs only accept chains that start with a known 456 root). Since TLSA Certificate Usage "2" is generally intended to 457 support non-PKIX trust anchors, clients SHOULD NOT perform CT checks 458 with usage "2" using unknown root CAs. A server operator that wants 459 CT checks SHOULD publish TLSA RRs with usage "0", or can obviate them 460 with usage "1" or "3". 462 CT checks remain applicable with TLSA Certificate Usage "0" when the 463 client supports both DANE and CT and the trusted PKIX root issuer is 464 a known public root. 466 3.8. Design Considerations for Protocols Using DANE 468 3.8.1. Design Considerations for non-PKIX Protocols 470 For some application protocols, the existing public CA PKI may not be 471 viable. For these (non-PKIX) protocols, servers SHOULD NOT suggest 472 publishing TLSA records with TLSA Certificate Usage "0" or "1", as 473 clients cannot be expected to perform [RFC5280] PKIX validation or 474 [RFC6125] identity verification. 476 Protocols designed for non-PKIX use SHOULD choose to treat any TLSA 477 records with TLSA Certificate Usage "0" or "1" as unusable. After 478 verifying that the only available TLSA Certificate Usage types are 479 "0" or "1", protocol definitions MAY instruct clients to either 480 refuse to initiate a connection or to connect via unauthenticated 481 mandatory TLS if no alternative authentication mechanisms are 482 available. 484 If non-PKIX protocols do allow for publication of TLSA records with 485 TLSA Certificate Usage "0" or "1", clients SHOULD make use of the 486 TLSA verification to the fullest extent possible. 488 3.8.1.1. TLSA Certificate Usage 1 490 With non-PKIX protocols, clients using TLSA Certificate Usage "1" 491 records MAY ignore the PKIX validation requirement, and authenticate 492 the server per the content of the TLSA record alone. Since servers 493 will hopefully rely on SNI to select the correct certificate for 494 presentation, the client SHOULD use the SNI extension to signal the 495 base domain of the TLSA RRset. 497 3.8.1.2. TLSA Certificate Usage 0 499 With TLSA Certificate Usage "0" in non-PKIX protocols, the usability 500 of the TLSA records depends on its matching type. 502 If the matching type is "0", the TLSA record contains the full 503 certificate or full public key of the trusted certificate authority. 504 In this case the client has all the information it needs to match the 505 server trust-chain to the TLSA record. The client MAY ignore the 506 PKIX validation requirement and authenticate the server via its DANE 507 TLSA records alone (sending SNI with the base domain as usual). The 508 client SHOULD use the base domain of the TLSA record(s) in 509 certificate name checks. 511 If the matching type is not "0", the TLSA record contains only a 512 digest of the trust certificate authority certificate or public key. 513 The full certificate may not be included in the server's certificate 514 chain and the client may not be able to match the server trust chain 515 against the TLSA record when a non-PKIX protocol is being used, as 516 the client won't have a default CA trust list. See Section 3.9.1 for 517 a more complete discussion of this case. The client cannot reliably 518 authenticate the server in this case and SHOULD treat the TLSA record 519 as unusable. 521 If the client is configured with a set of trusted CAs that are 522 believed to be sufficiently complete to authenticate all the servers 523 it expects to communicate with, then it MAY elect to honor 524 certificate usage "0" TLSA records that publish digests of the 525 trusted CA certificate or public key. 527 3.9. TLSA Records and Trust Anchor Digests 529 With TLSA records that match the EE certificate, the TLS client has 530 no difficulty matching the TLS record against the server certificate, 531 as this certificate is always present in the TLS server certificate 532 chain. The TLS client can, if necessary, extract the public key from 533 the server certificate, and can compute the appropriate digest. 535 With DANE TLSA records that match the digest of a TA certificate or 536 public key, a complication arises when the TA certificate is omitted 537 from the server's certificate chain. This can happen when the trust- 538 anchor is a root certificate authority, as stated in section 7.4.2 of 539 [RFC5246]: 541 The sender's certificate MUST come first in the list. Each 542 following certificate MUST directly certify the one preceding 543 it. Because certificate validation requires that root keys be 544 distributed independently, the self-signed certificate that 545 specifies the root certificate authority MAY be omitted from the 546 chain, under the assumption that the remote end must already 547 possess it in order to validate it in any case. 549 This means that TLSA records that match a TA certificate or public 550 key digest are not entirely sufficient to validate the peer 551 certificate chain. If no matching certificate is found in the 552 server's certificate chain, the chain may be signed by an omitted 553 root CA whose digest matches the TLSA record. We will consider each 554 trust-anchor TLSA Certificate Usage in turn. 556 3.9.1. Trust Anchor Digests With TLSA Certificate Usage 0 558 In this case, from the server's perspective, the omission of the root 559 CA seems reasonable, since in addition to authentication via DANE 560 TLSA records, the client is expected to perform [RFC5280] PKIX 561 validation of the server's trust chain and thus to already have a 562 copy of the omitted root certificate. 564 From the client's perspective the situation is more nuanced. Despite 565 the server's indicated preference for PKIX validation, the client may 566 not possess (or may not fully trust) a complete set of public root 567 CAs. This is especially likely in protocols where the existing 568 public CA PKI is not applicable, as described in Section 3.8.1. If 569 it is likely that a client lacks a sufficiently complete list of 570 trusted CAs, and that a non-negligible number of DNS servers publish 571 TLSA Certificate Usage 0 TLSA records with digests of omitted root 572 CAs, then such a client SHOULD treat such TLSA records as "unusable". 573 Simply ignoring PKIX validation is not an option, since the client 574 will also be unable to match the TLSA record without position of the 575 root certificate. The client MAY choose fall back to unauthenticated 576 TLS, if PKIX is also not an option (see [I-D.ietf-dane-srv]) or 577 refuse to initiate a connection. 579 3.9.2. Trust Anchor Digests With TLSA Certificate Usage 2 581 With TLSA Certificate Usage "2", there is no expectation that the 582 client is pre-configured with the trust anchor certificate. With 583 TLSA Certificate Usage "2" clients are expecting to rely on the TLSA 584 records alone. But, with a matching type other than "0" the TLSA 585 records contain neither the full trust anchor certificate nor the 586 full public key. If the TLS server's certificate chain does not 587 contain the trust-anchor certificate, clients will be unable to 588 authenticate the server. 590 TLSA Publishers that publish TLSA Certificate Usage "2" with a non- 591 zero matching type MUST ensure that the corresponding server is 592 configured to include the associated trust anchor certificate in its 593 TLS handshake certificate chain, even if that certificate is a self- 594 signed root CA and would have been optional in the context of the 595 existing public CA PKI. 597 Since servers are expected to always provide usage "2" trust anchor 598 certificates (either via DNS or else via the TLS hanshake), clients 599 SHOULD fully support this TLSA Certificate Usage. Clients MAY choose 600 to treat it as unusable if experience proves that servers don't 601 consistently live up to their obligations. 603 3.10. Trust anchor public keys 605 TLSA records with TLSA Certificate Usage "0" or "2", selector "1" and 606 a matching type of "0" publish the full public key of a trust anchor 607 via DNS. In section 6.1.1 of [RFC5280] the definition of a trust 608 anchor consists of the following four parts: 610 1. the trusted issuer name, 612 2. the trusted public key algorithm, 614 3. the trusted public key, and 616 4. optionally, the trusted public key parameters associated with the 617 public key. 619 Items 2-4 are precisely the contents of the subjectPublicKeyInfo 620 published in the TLSA record, but the issuer name is not included in 621 the public key. 623 With TLSA Certificate Usage "0", when the client is able to perform 624 PKIX validation, the client can construct a complete PKIX trust chain 625 as it will have access to the trust anchor name. So in that case, 626 the client can verify that the server certificate chain is issued by 627 a trust anchor that matches the TLSA record. 629 With TLSA Certificate Usage "2", the client may not have the missing 630 trust anchor certificate, and cannot generally verify whether a 631 particular certificate chain is "issued by" the trust anchor 632 described in the TLSA record. If the server certificate chain 633 includes a CA certificate whose public key matches the TLSA record, 634 the client can match that CA as the intended issuer. Otherwise, the 635 client can only check that the topmost certificate in the server's 636 chain is "signed by" by the trust anchor public key in the TLSA 637 record. 639 Since trust chain validation via bare public keys rather than trusted 640 CA certificates may be difficult to implement using existing TLS 641 libraries, servers SHOULD include the trust anchor certificate in 642 their certificate chain when the TLSA Certificate Usage is "2". 644 If none of the server's certificate chain elements match a public key 645 specified in full (selector = 0, match type = 0) in a TLSA record, 646 clients SHOULD attempt to check whether the topmost certificate in 647 the chain is signed by the provided public key, and if so consider 648 the server trust chain valid, with authentication complete if name 649 checks are also successful. 651 4. Type Specific DANE Guidelines 653 4.1. Type 3 Guidelines 655 4.2. Type 2 Guidelines 657 4.3. Type 1 Guidelines 659 4.4. Type 0 Guidelines 660 TLSA Certificate Usage "0" allows a domain to publish constraints on 661 the set of certificate authorities trusted to issue certificates for 662 its TLS servers. It is expected that clients will only accept trust 663 chains which contain a match for one of the published TLSA records. 664 This is simple for TLSA Certificate Usage "1" where the PKIX trust 665 chain always contains the leaf server certificate. The situation for 666 TLSA Certificate Usage "0" is more subtle. 668 TLSA Publishers may publish TLSA records for a particular public root 669 CA, expecting that clients will then only accept chains anchored at 670 that root. It is possible, however, that the client's set of trusted 671 certificates includes some intermediate CAs, either with or without 672 the corresponding root CA. When a client constructs a trust chain 673 leading from a trusted intermediate CA to the server leaf 674 certificate, such a chain may omit any trusted roots published in the 675 server's TLSA records. 677 If the omitted root is also trusted, the client may erroneously 678 reject the server chain if it fails to determine that the shorter 679 chain it constructed extends to a longer trusted chain that matches 680 the TLSA records. This means that a client SHOULD not always stop 681 extending the chain when the first locally trusted certificate is 682 found. If no TLSA records have matched any of the elements of the 683 chain, it MUST attempt to build a longer chain if the trusted 684 certificate found is not self-issued, in the hope that a certificate 685 closer to the root may in fact match the server's TLSA records. 687 5. Note on DNSSEC security 689 Clearly the security of the DANE TLSA PKI rests on the security of 690 the underlying DNSSEC infrastructure. While this memo is not a guide 691 to DNSSEC security, a few comments may be helpful to TLSA 692 implementors. 694 With the existing public CA PKI, name constraints are rarely used and 695 public root CAs can issue certificates for any domain of its choice. 696 With DNSSEC, the situation is different. Only the registrar of 697 record can update a domain's DS record in the registry parent zone 698 (in some cases, however, the registry is the sole registrar). With 699 gTLDs, for which multiple registrars compete to provide domains in a 700 single registry, it is important to make sure that rogue registrars 701 cannot easily initiate an unauthorized domain transfer, and thus take 702 over DNSSEC for the domain. DNS Operators SHOULD use a registrar 703 lock of their domains to offer some protection of this possibility. 705 When the registrar is also the DNS operator for the domain, one needs 706 to consider whether the registrar will allow orderly migration of the 707 domain to another registrar or DNS operator in a way that will 708 maintain DNSSEC integrity. TLSA Publishers SHOULD ensure their 709 registrar publishes a suitable domain transfer policy. 711 DNSSEC signed RRsets cannot be securely revoked before they expire. 712 Operators should plan accordingly and not generate signatures with 713 excessively long duration. For domains publishing high-value keys, a 714 signature lifetime of a few days is reasonable, and the zone should 715 be resigned every day. For more domains with less critical data, a 716 reasonable signature lifetime is a couple of weeks to a month, and 717 the zone should be resigned every week. Monitoring of the signature 718 lifetime is important. If the zone is not resigned in a timely 719 manner, one risks a major outage with the entire domain becoming 720 invalid. 722 6. Acknowledgements 724 The authors would like to thank Phil Pennock for his comments and 725 advice on this document. 727 Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded 728 me into participating in DANE working group discussions. Thanks to 729 Paul Hoffman who motivated me to produce this memo and provided 730 feedback on early drafts. 732 7. Security Considerations 734 Application protocols that cannot make use of the existing public CA 735 PKI (so called non-PKIX protocols), may choose to not implement 736 certain PKIX-dependent TLSA record types defined in [RFC6698], or may 737 choose to make a best-effort use of such records. In neither case is 738 security compromised, since by assumption PKIX verification is simply 739 not an option for these protocols. When the TLS server is 740 authenticated based on the TLSA records alone, the client is as well 741 authenticated as possible, treating the TLSA records as unusable 742 would lead to weaker security. 744 Therefore, when TLSA records are used with protocols where PKIX does 745 not apply, the recommended trade-off is for servers to not publish 746 PKIX-dependent TLSA records, and for clients to use them as best they 747 can, but otherwise treat them unusable. Of course when PKIX 748 validation is an option clients SHOULD perform PKIX validation per 749 [RFC6698]. 751 8. References 753 8.1. Normative References 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, March 1997. 758 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 759 RFC 2246, January 1999. 761 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 762 and T. Wright, "Transport Layer Security (TLS) 763 Extensions", RFC 3546, June 2003. 765 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 766 Rose, "DNS Security Introduction and Requirements", RFC 767 4033, March 2005. 769 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 770 Rose, "Resource Records for the DNS Security Extensions", 771 RFC 4034, March 2005. 773 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 774 Rose, "Protocol Modifications for the DNS Security 775 Extensions", RFC 4035, March 2005. 777 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 778 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 780 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 781 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 783 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 784 Housley, R., and W. Polk, "Internet X.509 Public Key 785 Infrastructure Certificate and Certificate Revocation List 786 (CRL) Profile", RFC 5280, May 2008. 788 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 789 Verification of Domain-Based Application Service Identity 790 within Internet Public Key Infrastructure Using X.509 791 (PKIX) Certificates in the Context of Transport Layer 792 Security (TLS)", RFC 6125, March 2011. 794 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 795 Security Version 1.2", RFC 6347, January 2012. 797 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 798 of Named Entities (DANE) Transport Layer Security (TLS) 799 Protocol: TLSA", RFC 6698, August 2012. 801 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 802 Transparency", RFC 6962, June 2013. 804 8.2. Informative References 806 [I-D.ietf-dane-srv] 807 Finch, T., "Using DNS-Based Authentication of Named 808 Entities (DANE) TLSA records with SRV and MX records.", 809 draft-ietf-dane-srv-02 (work in progress), February 2013. 811 Authors' Addresses 813 Viktor Dukhovni 814 Unaffiliated 816 Email: ietf-dane@dukhovni.org 818 Wes Hardaker 819 Parsons 820 P.O. Box 382 821 Davis, CA 95617 822 US 824 Email: ietf@hardakers.net