| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | DANE V. Dukhovni |
| 6 | Internet-Draft Unaffiliated |
| 7 | Intended status: Standards Track W. Hardaker |
| 8 | Expires: February 18, 2015 Parsons |
| 9 | August 17, 2014 |
| 10 | |
| 11 | |
| 12 | Updates to and Operational Guidance for the DANE Protocol |
| 13 | draft-ietf-dane-ops-06 |
| 14 | |
| 15 | Abstract |
| 16 | |
| 17 | This memo clarifies and updates the DANE TLSA protocol based on |
| 18 | implementation experience since the publication of the original DANE |
| 19 | specification in [RFC6698]. It also contains guidance for DANE |
| 20 | implementers and operators. |
| 21 | |
| 22 | Status of This Memo |
| 23 | |
| 24 | This Internet-Draft is submitted in full conformance with the |
| 25 | provisions of BCP 78 and BCP 79. |
| 26 | |
| 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/. |
| 31 | |
| 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." |
| 36 | |
| 37 | This Internet-Draft will expire on February 18, 2015. |
| 38 | |
| 39 | Copyright Notice |
| 40 | |
| 41 | Copyright (c) 2014 IETF Trust and the persons identified as the |
| 42 | document authors. All rights reserved. |
| 43 | |
| 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. |
| 53 | |
| 54 | |
| 55 | |
| 56 | Dukhovni & Hardaker Expires February 18, 2015 [Page 1] |
| 57 | \f |
| 58 | Internet-Draft DANE operations August 2014 |
| 59 | |
| 60 | |
| 61 | Table of Contents |
| 62 | |
| 63 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 |
| 64 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 |
| 65 | 2. DANE TLSA Record Overview . . . . . . . . . . . . . . . . . . 4 |
| 66 | 2.1. Example TLSA record . . . . . . . . . . . . . . . . . . . 6 |
| 67 | 3. DANE TLS Requirements . . . . . . . . . . . . . . . . . . . . 6 |
| 68 | 4. Certificate-Usage-Specific DANE Updates and Guidelines . . . 7 |
| 69 | 4.1. Certificate Usage DANE-EE(3) . . . . . . . . . . . . . . 7 |
| 70 | 4.2. Certificate Usage DANE-TA(2) . . . . . . . . . . . . . . 8 |
| 71 | 4.3. Certificate Usage PKIX-EE(1) . . . . . . . . . . . . . . 11 |
| 72 | 4.4. Certificate Usage PKIX-TA(0) . . . . . . . . . . . . . . 12 |
| 73 | 4.5. Opportunistic Security and PKIX usages . . . . . . . . . 12 |
| 74 | 5. Service Provider and TLSA Publisher Synchronization . . . . . 13 |
| 75 | 6. TLSA Base Domain and CNAMEs . . . . . . . . . . . . . . . . . 15 |
| 76 | 7. TLSA Publisher Requirements . . . . . . . . . . . . . . . . . 16 |
| 77 | 7.1. Key rollover with fixed TLSA Parameters . . . . . . . . . 17 |
| 78 | 7.2. Switching to DANE-TA from DANE-EE . . . . . . . . . . . . 18 |
| 79 | 7.3. Switching to New TLSA Parameters . . . . . . . . . . . . 18 |
| 80 | 7.4. TLSA Publisher Requirements Summary . . . . . . . . . . . 19 |
| 81 | 8. Digest Algorithm Agility . . . . . . . . . . . . . . . . . . 19 |
| 82 | 9. General DANE Guidelines . . . . . . . . . . . . . . . . . . . 20 |
| 83 | 9.1. DANE DNS Record Size Guidelines . . . . . . . . . . . . . 21 |
| 84 | 9.2. Certificate Name Check Conventions . . . . . . . . . . . 21 |
| 85 | 9.3. Design Considerations for Protocols Using DANE . . . . . 23 |
| 86 | 10. Interaction with Certificate Transparency . . . . . . . . . . 23 |
| 87 | 11. Note on DNSSEC Security . . . . . . . . . . . . . . . . . . . 24 |
| 88 | 12. Summary of Updates to RFC6698 . . . . . . . . . . . . . . . . 25 |
| 89 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 |
| 90 | 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 |
| 91 | 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 |
| 92 | 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 93 | 16.1. Normative References . . . . . . . . . . . . . . . . . . 27 |
| 94 | 16.2. Informative References . . . . . . . . . . . . . . . . . 28 |
| 95 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 96 | |
| 97 | 1. Introduction |
| 98 | |
| 99 | [RFC6698] specifies a new DNS resource record "TLSA" that associates |
| 100 | a public certificate or public key of a trusted leaf or issuing |
| 101 | authority with the corresponding TLS transport endpoint. These DANE |
| 102 | TLSA records, when validated by DNSSEC, can be used to augment or |
| 103 | replace the trust model of the existing public Certification |
| 104 | Authority (CA) Public Key Infrastructure (PKI). |
| 105 | |
| 106 | [RFC6698] defines three TLSA record fields with respectively 4, 2 and |
| 107 | 3 currently specified values. These yield 24 distinct combinations |
| 108 | of TLSA record types. This many options have lead to implementation |
| 109 | |
| 110 | |
| 111 | |
| 112 | Dukhovni & Hardaker Expires February 18, 2015 [Page 2] |
| 113 | \f |
| 114 | Internet-Draft DANE operations August 2014 |
| 115 | |
| 116 | |
| 117 | and operational complexity. This memo will recommend best-practice |
| 118 | choices to help simplify implementation and deployment given these |
| 119 | plethora of choices. |
| 120 | |
| 121 | Implementation complexity also arises from the fact that the TLS |
| 122 | transport endpoint is often specified indirectly via Service Records |
| 123 | (SRV), Mail Exchange (MX) records, CNAME records or other mechanisms |
| 124 | that map an abstract service domain to a concrete server domain. |
| 125 | With service indirection there are multiple potential places for |
| 126 | clients to find the relevant TLSA records. Service indirection is |
| 127 | often used to implement "virtual hosting", where a single Service |
| 128 | Provider transport endpoint simultaneously supports multiple hosted |
| 129 | domain names. With services that employ TLS, such hosting |
| 130 | arrangements may require the Service Provider to deploy multiple |
| 131 | pairs of private keys and certificates with TLS clients signaling the |
| 132 | desired domain via the Server Name Indication (SNI) extension |
| 133 | ([RFC6066], section 3). This memo provides operational guidelines |
| 134 | intended to maximize interoperability between DANE TLS clients and |
| 135 | servers. |
| 136 | |
| 137 | In the context of this memo, channel security is assumed to be |
| 138 | provided by TLS or DTLS. The Transport Layer Security (TLS) |
| 139 | [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347] |
| 140 | protocols provide secured TCP and UDP communication over IP. By |
| 141 | convention, "TLS" will be used throughout this document and, unless |
| 142 | otherwise specified, the text applies equally well to the DTLS |
| 143 | protocol. Used without authentication, TLS provides protection only |
| 144 | against eavesdropping through its use of encryption. With |
| 145 | authentication, TLS also provides integrity protection and |
| 146 | authentication, which protect the transport against man-in-the-middle |
| 147 | (MITM) attacks. |
| 148 | |
| 149 | Other related documents that build on [RFC6698] are |
| 150 | [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]. In |
| 151 | Section 12 we summarize the updates this document makes to [RFC6698]. |
| 152 | |
| 153 | 1.1. Terminology |
| 154 | |
| 155 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| 156 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and |
| 157 | "OPTIONAL" in this document are to be interpreted as described in |
| 158 | [RFC2119]. |
| 159 | |
| 160 | The following terms are used throughout this document: |
| 161 | |
| 162 | Service Provider: A company or organization that offers to host a |
| 163 | service on behalf of a Customer Domain. The original domain name |
| 164 | associated with the service often remains under the control of the |
| 165 | |
| 166 | |
| 167 | |
| 168 | Dukhovni & Hardaker Expires February 18, 2015 [Page 3] |
| 169 | \f |
| 170 | Internet-Draft DANE operations August 2014 |
| 171 | |
| 172 | |
| 173 | customer. Connecting applications may be directed to the Service |
| 174 | Provider via a redirection resource record. Example redirection |
| 175 | records include MX, SRV, and CNAME. The Service Provider |
| 176 | frequently provides services for many customers and must carefully |
| 177 | manage any TLS credentials offered to connecting applications to |
| 178 | ensure name matching is handled easily by the applications. |
| 179 | |
| 180 | Customer Domain: As described above, a client may be interacting |
| 181 | with a service that is hosted by a third party. We will refer to |
| 182 | the domain name used to locate the service prior to any |
| 183 | redirection, as the "Customer Domain". |
| 184 | |
| 185 | TLSA Publisher: The entity responsible for publishing a TLSA record |
| 186 | within a DNS zone. This zone will be assumed DNSSEC-signed and |
| 187 | validatable to a trust anchor, unless otherwise specified. If the |
| 188 | Customer Domain is not outsourcing their DNS service, the TLSA |
| 189 | Publisher will be the customer themselves. Otherwise, the TLSA |
| 190 | Publisher is sometimes the operator of the outsourced DNS service. |
| 191 | |
| 192 | public key: The term "public key" is short-hand for the |
| 193 | subjectPublicKeyInfo component of a PKIX [RFC5280] certificate. |
| 194 | |
| 195 | SNI: The "Server Name Indication" (SNI) TLS protocol extension |
| 196 | allows a TLS client to request a connection to a particular |
| 197 | service name of a TLS server ([RFC6066], section 3). Without this |
| 198 | TLS extension, a TLS server has no choice but to offer a PKIX |
| 199 | certificate with a default list of server names, making it |
| 200 | difficult to host multiple Customer Domains at the same IP- |
| 201 | addressed based TLS service endpoint (i.e., "secure virtual |
| 202 | hosting"). |
| 203 | |
| 204 | TLSA parameters: In [RFC6698] the TLSA record is defined to consist |
| 205 | of four fields. The first three of these are numeric parameters |
| 206 | that specify the meaning of the data in fourth and final field. |
| 207 | To avoid language contortions when we need to distinguish between |
| 208 | the first three fields that together define a TLSA record "type" |
| 209 | and the fourth that provides a data value of that type, we will |
| 210 | call the first three fields "TLSA parameters", or sometimes just |
| 211 | "parameters" when obvious from context. |
| 212 | |
| 213 | 2. DANE TLSA Record Overview |
| 214 | |
| 215 | |
| 216 | |
| 217 | |
| 218 | |
| 219 | |
| 220 | |
| 221 | |
| 222 | |
| 223 | |
| 224 | Dukhovni & Hardaker Expires February 18, 2015 [Page 4] |
| 225 | \f |
| 226 | Internet-Draft DANE operations August 2014 |
| 227 | |
| 228 | |
| 229 | DANE TLSA [RFC6698] specifies a protocol for publishing TLS server |
| 230 | certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035]. |
| 231 | The DANE TLSA specification defines multiple TLSA RR types via |
| 232 | combinations of numeric values of the first three fields of the TLSA |
| 233 | record (i.e. the "TLSA parameters"). The numeric values of these |
| 234 | parameters were later given symbolic names in [RFC7218]. These |
| 235 | parameters are: |
| 236 | |
| 237 | The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies 4 |
| 238 | values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3). There |
| 239 | is an additional private-use value: PrivCert(255). All other |
| 240 | values are reserved for use by future specifications. |
| 241 | |
| 242 | The selector field: Section 2.1.2 of [RFC6698] specifies 2 values: |
| 243 | Cert(0), SPKI(1). There is an additional private-use value: |
| 244 | PrivSel(255). All other values are reserved for use by future |
| 245 | specifications. |
| 246 | |
| 247 | The matching type field: Section 2.1.3 of [RFC6698] specifies 3 |
| 248 | values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional |
| 249 | private-use value: PrivMatch(255). All other values are reserved |
| 250 | for use by future specifications. |
| 251 | |
| 252 | We may think of TLSA Certificate Usage values 0 through 3 as a |
| 253 | combination of two one-bit flags. The low-bit chooses between trust |
| 254 | anchor (TA) and end entity (EE) certificates. The high bit chooses |
| 255 | between PKIX, or public PKI issued, and DANE, or domain-issued trust |
| 256 | anchors: |
| 257 | |
| 258 | o When the low bit is set (PKIX-EE(1) and DANE-EE(3)) the TLSA |
| 259 | record matches an EE certificate (also commonly referred to as a |
| 260 | leaf or server certificate.) |
| 261 | |
| 262 | o When the low bit is not set (PKIX-TA(0) and DANE-TA(2)) the TLSA |
| 263 | record matches a trust anchor (a Certification Authority) that |
| 264 | issued one of the certificates in the server certificate chain. |
| 265 | |
| 266 | o When the high bit is set (DANE-TA(2) and DANE-EE(3)), the server |
| 267 | certificate chain is domain-issued and may be verified without |
| 268 | reference to any pre-existing public certification authority PKI. |
| 269 | Trust is entirely placed on the content of the TLSA records |
| 270 | obtained via DNSSEC. |
| 271 | |
| 272 | |
| 273 | |
| 274 | |
| 275 | |
| 276 | |
| 277 | |
| 278 | |
| 279 | |
| 280 | Dukhovni & Hardaker Expires February 18, 2015 [Page 5] |
| 281 | \f |
| 282 | Internet-Draft DANE operations August 2014 |
| 283 | |
| 284 | |
| 285 | o When the high bit is not set (PKIX-TA(0) and PKIX-EE(1)), the TLSA |
| 286 | record publishes a server policy stating that its certificate |
| 287 | chain must pass PKIX validation [RFC5280] and the DANE TLSA record |
| 288 | is used to signal an additional requirement that the PKIX |
| 289 | validated server certificate chain also contains the referenced CA |
| 290 | or EE certificate. |
| 291 | |
| 292 | The selector field specifies whether the TLSA RR matches the whole |
| 293 | certificate (Cert(0)) or just its subjectPublicKeyInfo (SPKI(1)). |
| 294 | The subjectPublicKeyInfo is an ASN.1 DER encoding of the |
| 295 | certificate's algorithm id, any parameters and the public key data. |
| 296 | |
| 297 | The matching type field specifies how the TLSA RR Certificate |
| 298 | Association Data field is to be compared with the certificate or |
| 299 | public key. A value of Full(0) means an exact match: the full DER |
| 300 | encoding of the certificate or public key is given in the TLSA RR. A |
| 301 | value of SHA2-256(1) means that the association data matches the |
| 302 | SHA2-256 digest of the certificate or public key, and likewise |
| 303 | SHA2-512(2) means a SHA2-512 digest is used. Of the two digest |
| 304 | algorithms, for now only SHA2-256(1) is mandatory to implement. |
| 305 | Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT |
| 306 | exclusively publish SHA2-512(2) digests. The digest algorithm |
| 307 | agility protocol defined in Section 8 SHOULD be used by clients to |
| 308 | decide how to process TLSA RRsets that employ multiple digest |
| 309 | algorithms. Server operators MUST publish TLSA RRsets that are |
| 310 | compatible with digest algorithm agility. |
| 311 | |
| 312 | 2.1. Example TLSA record |
| 313 | |
| 314 | In the example TLSA record below: |
| 315 | |
| 316 | _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 ( |
| 317 | E8B54E0B4BAA815B06D3462D65FBC7C0 |
| 318 | CF556ECCF9F5303EBFBB77D022F834C0 ) |
| 319 | |
| 320 | The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and |
| 321 | the matching type is SHA2-256(1). The last field is the Certificate |
| 322 | Association Data Field, which in this case contains the SHA2-256 |
| 323 | digest of the server certificate. |
| 324 | |
| 325 | 3. DANE TLS Requirements |
| 326 | |
| 327 | [RFC6698] does not discuss what versions of TLS are required when |
| 328 | using DANE records. This document specifies that TLS clients that |
| 329 | support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support |
| 330 | TLS 1.2. TLS clients and servers using DANE SHOULD support the |
| 331 | "Server Name Indication" (SNI) extension of TLS. |
| 332 | |
| 333 | |
| 334 | |
| 335 | |
| 336 | Dukhovni & Hardaker Expires February 18, 2015 [Page 6] |
| 337 | \f |
| 338 | Internet-Draft DANE operations August 2014 |
| 339 | |
| 340 | |
| 341 | 4. Certificate-Usage-Specific DANE Updates and Guidelines |
| 342 | |
| 343 | The four Certificate Usage values from the TLSA record, DANE-EE(3), |
| 344 | DANE-TA(2), PKIX-EE(1) and PKIX-TA(0), are discussed below. |
| 345 | |
| 346 | 4.1. Certificate Usage DANE-EE(3) |
| 347 | |
| 348 | In this section the meaning of DANE-EE(3) is updated from [RFC6698] |
| 349 | to specify that peer identity matching and that validity interval |
| 350 | compliance is based solely on the TLSA RRset properties. We also |
| 351 | extend [RFC6698] to cover the use of DANE authentication of raw |
| 352 | public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with |
| 353 | Certificate Usage DANE-EE(3) and selector SPKI(1). |
| 354 | |
| 355 | Authentication via certificate usage DANE-EE(3) TLSA records involves |
| 356 | simply checking that the server's leaf certificate matches the TLSA |
| 357 | record. In particular, the binding of the server public key to its |
| 358 | name is based entirely on the TLSA record association. The server |
| 359 | MUST be considered authenticated even if none of the names in the |
| 360 | certificate match the client's reference identity for the server. |
| 361 | |
| 362 | Similarly, with DANE-EE(3), the expiration date of the server |
| 363 | certificate MUST be ignored. The validity period of the TLSA record |
| 364 | key binding is determined by the validity interval of the TLSA record |
| 365 | DNSSEC signatures. |
| 366 | |
| 367 | With DANE-EE(3) servers that know all the connecting clients are |
| 368 | making use of DANE, they need not employ SNI (i.e., the may ignore |
| 369 | the client's SNI message) even when the server is known under |
| 370 | multiple domain names that would otherwise require separate |
| 371 | certificates. It is instead sufficient for the TLSA RRsets for all |
| 372 | the domain names in question to match the server's primary |
| 373 | certificate. For application protocols where the server name is |
| 374 | obtained indirectly via SRV, MX or similar records, it is simplest to |
| 375 | publish a single hostname as the target server name for all the |
| 376 | hosted domains. |
| 377 | |
| 378 | In organizations where it is practical to make coordinated changes in |
| 379 | DNS TLSA records before server key rotation, it is generally best to |
| 380 | publish end-entity DANE-EE(3) certificate associations in preference |
| 381 | to other choices of certificate usage. DANE-EE(3) TLSA records |
| 382 | support multiple server names without SNI, don't suddenly stop |
| 383 | working when leaf or intermediate certificates expire, and don't fail |
| 384 | when a server operator neglects to include all the required issuer |
| 385 | certificates in the server certificate chain. |
| 386 | |
| 387 | TLSA records published for DANE servers SHOULD, as a best practice, |
| 388 | be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE |
| 389 | |
| 390 | |
| 391 | |
| 392 | Dukhovni & Hardaker Expires February 18, 2015 [Page 7] |
| 393 | \f |
| 394 | Internet-Draft DANE operations August 2014 |
| 395 | |
| 396 | |
| 397 | implementations are required to support SHA2-256, this record type |
| 398 | works for all clients and need not change across certificate renewals |
| 399 | with the same key. This TLSA record type easily supports hosting |
| 400 | arrangements with a single certificate matching all hosted domains. |
| 401 | It is also the easiest to implement correctly in the client. |
| 402 | |
| 403 | Another advantage of "DANE-EE(3) SPKI(1)" (with any suitable matching |
| 404 | type) TLSA records is that they are compatible with the raw public |
| 405 | key TLS extension specified in [I-D.ietf-tls-oob-pubkey]. DANE |
| 406 | clients that support this extension can use the TLSA record to |
| 407 | authenticate servers that negotiate the use of raw public keys in |
| 408 | place of X.509 certificate chains. Provided the server adheres to |
| 409 | the requirements of Section 7, the fact that raw public keys are not |
| 410 | compatible with any other TLSA record types will not get in the way |
| 411 | of successful authentication. Clients that employ DANE to |
| 412 | authenticate the peer server SHOULD NOT negotiate the use of raw |
| 413 | public keys unless the server's TLSA RRset includes compatible TLSA |
| 414 | records. |
| 415 | |
| 416 | While it is, in principle, also possible to authenticate raw public |
| 417 | keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the |
| 418 | public key from the certificate in DNS, this is in conflict with the |
| 419 | indicated selector and requires extra logic on clients that not all |
| 420 | implementations are expected to provide. Servers SHOULD NOT rely on |
| 421 | "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication |
| 422 | data for raw public keys. |
| 423 | |
| 424 | 4.2. Certificate Usage DANE-TA(2) |
| 425 | |
| 426 | This section updates [RFC6698] by specifying a new operational |
| 427 | requirement for servers publishing TLSA records with a usage of DANE- |
| 428 | TA(2): such servers MUST include the trust-anchor certificate in |
| 429 | their TLS server certificate message. |
| 430 | |
| 431 | Some domains may prefer to avoid the operational complexity of |
| 432 | publishing unique TLSA RRs for each TLS service. If the domain |
| 433 | employs a common issuing Certification Authority to create |
| 434 | certificates for multiple TLS services, it may be simpler to publish |
| 435 | the issuing authority as a trust anchor (TA) for the certificate |
| 436 | chains of all relevant services. The TLSA query domain (TLSA base |
| 437 | domain with port and protocol prefix labels) for each service issued |
| 438 | by the same TA may then be set to a CNAME alias that points to a |
| 439 | common TLSA RRset that matches the TA. For example: |
| 440 | |
| 441 | |
| 442 | |
| 443 | |
| 444 | |
| 445 | |
| 446 | |
| 447 | |
| 448 | Dukhovni & Hardaker Expires February 18, 2015 [Page 8] |
| 449 | \f |
| 450 | Internet-Draft DANE operations August 2014 |
| 451 | |
| 452 | |
| 453 | www1.example.com. IN A 192.0.2.1 |
| 454 | www2.example.com. IN A 192.0.2.2 |
| 455 | _443._tcp.www1.example.com. IN CNAME tlsa201._dane.example.com. |
| 456 | _443._tcp.www2.example.com. IN CNAME tlsa201._dane.example.com. |
| 457 | tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14... |
| 458 | |
| 459 | With usage DANE-TA(2) the server certificates will need to have names |
| 460 | that match one of the client's reference identifiers (see [RFC6125]). |
| 461 | The server SHOULD employ SNI to select the appropriate certificate to |
| 462 | present to the client. |
| 463 | |
| 464 | 4.2.1. Recommended record combinations |
| 465 | |
| 466 | TLSA records with selector Full(0) are NOT RECOMMENDED. While these |
| 467 | potentially obviate the need to transmit the TA certificate in the |
| 468 | TLS server certificate message, client implementations may not be |
| 469 | able to augment the server certificate chain with the data obtained |
| 470 | from DNS, especially when the TLSA record supplies a bare key |
| 471 | (selector SPKI(1)). Since the server will need to transmit the TA |
| 472 | certificate in any case, server operators SHOULD publish TLSA records |
| 473 | with a selector other than Full(0) and avoid potential DNS |
| 474 | interoperability issues with large TLSA records containing full |
| 475 | certificates or keys (see Section 9.1.1). |
| 476 | |
| 477 | TLSA Publishers employing DANE-TA(2) records SHOULD publish records |
| 478 | with a selector of Cert(0). Such TLSA records are associated with |
| 479 | the whole trust anchor certificate, not just with the trust anchor |
| 480 | public key. In particular, the client SHOULD then apply any relevant |
| 481 | constraints from the trust anchor certificate, such as, for example, |
| 482 | path length constraints. |
| 483 | |
| 484 | While a selector of SPKI(1) may also be employed, the resulting TLSA |
| 485 | record will not specify the full trust anchor certificate content, |
| 486 | and elements of the trust anchor certificate other than the public |
| 487 | key become mutable. This may, for example, enable a subsidiary CA to |
| 488 | issue a chain that violates the trust anchor's path length or name |
| 489 | constraints. |
| 490 | |
| 491 | 4.2.2. Trust anchor digests and server certificate chain |
| 492 | |
| 493 | With DANE-TA(2) (these TLSA records are expected to match the digest |
| 494 | of a TA certificate or public key), a complication arises when the TA |
| 495 | certificate is omitted from the server's certificate chain, perhaps |
| 496 | on the basis of Section 7.4.2 of [RFC5246]: |
| 497 | |
| 498 | |
| 499 | |
| 500 | |
| 501 | |
| 502 | |
| 503 | |
| 504 | Dukhovni & Hardaker Expires February 18, 2015 [Page 9] |
| 505 | \f |
| 506 | Internet-Draft DANE operations August 2014 |
| 507 | |
| 508 | |
| 509 | The sender's certificate MUST come first in the list. Each |
| 510 | following certificate MUST directly certify the one preceding |
| 511 | it. Because certificate validation requires that root keys be |
| 512 | distributed independently, the self-signed certificate that |
| 513 | specifies the root certification authority MAY be omitted from |
| 514 | the chain, under the assumption that the remote end must |
| 515 | already possess it in order to validate it in any case. |
| 516 | |
| 517 | With TLSA Certificate Usage DANE-TA(2), there is no expectation that |
| 518 | the client is pre-configured with the trust anchor certificate. In |
| 519 | fact, client implementations are free to ignore all locally |
| 520 | configured trust anchors when processing usage DANE-TA(2) TLSA |
| 521 | records and may rely exclusively on the certificates provided in the |
| 522 | server's certificate chain. But, with a digest in the TLSA record, |
| 523 | the TLSA record contains neither the full trust anchor certificate |
| 524 | nor the full public key. If the TLS server's certificate chain does |
| 525 | not contain the trust anchor certificate, DANE clients will be unable |
| 526 | to authenticate the server. |
| 527 | |
| 528 | TLSA Publishers that publish TLSA Certificate Usage DANE-TA(2) |
| 529 | associations with a selector of SPKI(1) or using a digest-based |
| 530 | matching type (not Full(0)) MUST ensure that the corresponding server |
| 531 | is configured to also include the trust anchor certificate in its TLS |
| 532 | handshake certificate chain, even if that certificate is a self- |
| 533 | signed root CA and would have been optional in the context of the |
| 534 | existing public CA PKI. |
| 535 | |
| 536 | 4.2.3. Trust anchor public keys |
| 537 | |
| 538 | TLSA records with TLSA Certificate Usage DANE-TA(2), selector SPKI(1) |
| 539 | and a matching type of Full(0) will publish the full public key of a |
| 540 | trust anchor via DNS. In section 6.1.1 of [RFC5280] the definition |
| 541 | of a trust anchor consists of the following four parts: |
| 542 | |
| 543 | 1. the trusted issuer name, |
| 544 | |
| 545 | 2. the trusted public key algorithm, |
| 546 | |
| 547 | 3. the trusted public key, and |
| 548 | |
| 549 | 4. optionally, the trusted public key parameters associated with the |
| 550 | public key. |
| 551 | |
| 552 | Items 2-4 are precisely the contents of the subjectPublicKeyInfo |
| 553 | published in the TLSA record. The issuer name is not included in the |
| 554 | subjectPublicKeyInfo. |
| 555 | |
| 556 | |
| 557 | |
| 558 | |
| 559 | |
| 560 | Dukhovni & Hardaker Expires February 18, 2015 [Page 10] |
| 561 | \f |
| 562 | Internet-Draft DANE operations August 2014 |
| 563 | |
| 564 | |
| 565 | With TLSA Certificate Usage DANE-TA(2), the client may not have the |
| 566 | associated trust anchor certificate, and cannot generally verify |
| 567 | whether a particular certificate chain is "issued by" the trust |
| 568 | anchor described in the TLSA record. |
| 569 | |
| 570 | When the server certificate chain includes a CA certificate whose |
| 571 | public key matches the TLSA record, the client can match that CA as |
| 572 | the intended issuer. Otherwise, the client can only check that the |
| 573 | topmost certificate in the server's chain is "signed by" the trust |
| 574 | anchor's public key in the TLSA record. Such a check may be |
| 575 | difficult to implement, and cannot be expected to be supported by all |
| 576 | clients. |
| 577 | |
| 578 | Thus, servers should not rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA |
| 579 | records to be sufficient to authenticate chains issued by the |
| 580 | associated public key in the absence of a corresponding certificate |
| 581 | in the server's TLS certificate message. Servers SHOULD include the |
| 582 | TA certificate in their certificate chain. |
| 583 | |
| 584 | If none of the server's certificate chain elements match a public key |
| 585 | specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1) |
| 586 | Full(0)" TLSA record is available, clients are encouraged to check |
| 587 | whether the topmost certificate in the chain is signed by the |
| 588 | provided public key and has not expired, and in that case consider |
| 589 | the server authenticated, provided the rest of the chain passes |
| 590 | validation including leaf certificate name checks. |
| 591 | |
| 592 | 4.3. Certificate Usage PKIX-EE(1) |
| 593 | |
| 594 | This Certificate Usage is similar to DANE-EE(3), but in addition PKIX |
| 595 | verification is required. Therefore, name checks, certificate |
| 596 | expiration, etc., apply as they would without DANE. When, for a |
| 597 | given application protocol, DANE clients support both DANE-EE(3) and |
| 598 | PKIX-EE(1) usages, it should be noted that an attacker who can |
| 599 | compromise DNSSEC can replace these with usage DANE-EE(3) or DANE- |
| 600 | TA(2) TLSA records of their choosing, and thus bypass any PKIX |
| 601 | verification requirements. |
| 602 | |
| 603 | Therefore, except when applications support only the PKIX Certificate |
| 604 | Usages (0 and 1), this Certificate Usage offers only illusory |
| 605 | incremental security over usage DANE-EE(3). It provides lower |
| 606 | operational reliability than DANE-EE(3) since some clients may not be |
| 607 | configured with the required root CA, the server's chain may be |
| 608 | incomplete or name checks may fail. PKIX-EE(1) also requires more |
| 609 | complex coordination between the Customer Domain and the Service |
| 610 | Provider in hosting arrangements. This certificate usage is NOT |
| 611 | RECOMMENDED. |
| 612 | |
| 613 | |
| 614 | |
| 615 | |
| 616 | Dukhovni & Hardaker Expires February 18, 2015 [Page 11] |
| 617 | \f |
| 618 | Internet-Draft DANE operations August 2014 |
| 619 | |
| 620 | |
| 621 | 4.4. Certificate Usage PKIX-TA(0) |
| 622 | |
| 623 | This section updates [RFC6698] by specifying new client |
| 624 | implementation requirements. Clients that trust intermediate |
| 625 | certificates MUST be prepared to construct longer PKIX chains than |
| 626 | would be required for PKIX alone. |
| 627 | |
| 628 | TLSA Certificate Usage PKIX-TA(0) allows a domain to publish |
| 629 | constraints on the set of PKIX certification authorities trusted to |
| 630 | issue certificates for its TLS servers. This TLSA record matches |
| 631 | PKIX-verified trust chains which contain an issuer certificate (root |
| 632 | or intermediate) that matches its association data field (typically a |
| 633 | certificate or digest). |
| 634 | |
| 635 | As with PKIX-EE(1) case, an attacker who can compromise DNSSEC can |
| 636 | replace these with usage DANE-EE(3) or DANE-TA(2) TLSA records of his |
| 637 | choosing and thus bypass the PKIX verification requirements. |
| 638 | Therefore, except when applications support only the PKIX Certificate |
| 639 | Usages (0 and 1), this Certificate Usage offers only illusory |
| 640 | incremental security over usage DANE-TA(2). It provides lower |
| 641 | operational reliability than DANE-TA(2) since some clients may not be |
| 642 | configured with the required root CA. PKIX-TA(0) also requires more |
| 643 | complex coordination between the Customer Domain and the Service |
| 644 | Provider in hosting arrangements. This certificate usage is NOT |
| 645 | RECOMMENDED. |
| 646 | |
| 647 | TLSA Publishers who publish TLSA records for a particular public root |
| 648 | CA, will expect that clients will then only accept chains anchored at |
| 649 | that root. It is possible, however, that the client's trusted |
| 650 | certificate store includes some intermediate CAs, either with or |
| 651 | without the corresponding root CA. When a client constructs a trust |
| 652 | chain leading from a trusted intermediate CA to the server leaf |
| 653 | certificate, such a "truncated" chain might not contain the trusted |
| 654 | root published in the server's TLSA record. |
| 655 | |
| 656 | If the omitted root is also trusted, the client may erroneously |
| 657 | reject the server chain if it fails to determine that the shorter |
| 658 | chain it constructed extends to a longer trusted chain that matches |
| 659 | the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record, |
| 660 | a client SHOULD NOT always stop extending the chain when the first |
| 661 | locally trusted certificate is found. If no TLSA records have |
| 662 | matched any of the elements of the chain, and the trusted certificate |
| 663 | found is not self-issued, the client MUST attempt to build a longer |
| 664 | chain in the hope that a certificate closer to the root may in fact |
| 665 | match the server's TLSA record. |
| 666 | |
| 667 | 4.5. Opportunistic Security and PKIX usages |
| 668 | |
| 669 | |
| 670 | |
| 671 | |
| 672 | Dukhovni & Hardaker Expires February 18, 2015 [Page 12] |
| 673 | \f |
| 674 | Internet-Draft DANE operations August 2014 |
| 675 | |
| 676 | |
| 677 | When the client's protocol design is based on Opportunistic Security |
| 678 | (OS, [I-D.dukhovni-opportunistic-security]), and authentication is |
| 679 | opportunistically employed based on the presence of server TLSA |
| 680 | records, it is especially important to avoid the PKIX-EE(1) and PKIX- |
| 681 | TA(0) certificate usages. This is because the client has no way to |
| 682 | know in advance that it and the server both trust the requisite root |
| 683 | CA. Use of authentication in OS needs to be employed only when the |
| 684 | client can be confident of success, absent an attack, or an |
| 685 | operational error on the server side. |
| 686 | |
| 687 | 5. Service Provider and TLSA Publisher Synchronization |
| 688 | |
| 689 | Complications arise when the TLSA Publisher is not the same entity as |
| 690 | the Service Provider. In this situation, the TLSA Publisher and the |
| 691 | Service Provider must cooperate to ensure that TLSA records published |
| 692 | by the TLSA Publisher don't fall out of sync with the server |
| 693 | certificate used by the Service Provider. |
| 694 | |
| 695 | Whenever possible, the TLSA Publisher and the Service Provider should |
| 696 | be the same entity. Otherwise, changes in the service certificate |
| 697 | chain must be carefully coordinated between the parties involved. |
| 698 | Such coordination is difficult and service outages will result when |
| 699 | coordination fails. |
| 700 | |
| 701 | Having the master TLSA record in the Service Provider's zone avoids |
| 702 | the complexity of bilateral coordination of server certificate |
| 703 | configuration and TLSA record management. Even when the TLSA RRset |
| 704 | must be published in the Customer Domain's DNS zone (perhaps the |
| 705 | client application does not "chase" CNAMEs to the TLSA base domain), |
| 706 | it is possible to employ CNAME records to delegate the content of the |
| 707 | TLSA RRset to a domain operated by the Service Provider. Certificate |
| 708 | name checks generally constrain the applicability of TLSA CNAMEs |
| 709 | across organizational boundaries to Certificate Usages DANE-EE(3) and |
| 710 | DANE-TA(2): |
| 711 | |
| 712 | Certificate Usage DANE-EE(3): In this case the Service Provider can |
| 713 | publish a single TLSA RRset that matches the server certificate or |
| 714 | public key digest. The same RRset works for all Customer Domains |
| 715 | because name checks do not apply with DANE-EE(3) TLSA records (see |
| 716 | Section 4.1). A Customer Domain can create a CNAME record |
| 717 | pointing to the TLSA RRset published by the Service Provider. |
| 718 | |
| 719 | Certificate Usage DANE-TA(2): When the Service Provider operates a |
| 720 | private certification authority, the Service Provider is free to |
| 721 | issue a certificate bearing any customer's domain name. Without |
| 722 | DANE, such a certificate would not pass trust verification, but |
| 723 | with DANE, the customer's TLSA RRset that is aliased to the |
| 724 | provider's TLSA RRset can delegate authority to the provider's CA |
| 725 | |
| 726 | |
| 727 | |
| 728 | Dukhovni & Hardaker Expires February 18, 2015 [Page 13] |
| 729 | \f |
| 730 | Internet-Draft DANE operations August 2014 |
| 731 | |
| 732 | |
| 733 | for the corresponding service. The Service Provider can generate |
| 734 | appropriate certificates for each customer and use the SNI |
| 735 | information provided by clients to select the right certificate |
| 736 | chain to present to each client. |
| 737 | |
| 738 | Below are example DNS records (assumed "secure" and shown without the |
| 739 | associated DNSSEC information, such as record signatures) that |
| 740 | illustrate both of of the above models in the case of an HTTPS |
| 741 | service whose clients all support DANE TLS. These examples work even |
| 742 | with clients that don't "chase" CNAMEs when constructing the TLSA |
| 743 | base domain (see Section 6 below). |
| 744 | |
| 745 | ; The hosted web service is redirected via a CNAME alias. |
| 746 | ; The associated TLSA RRset is also redirected via a CNAME alias. |
| 747 | ; |
| 748 | ; A single certificate at the provider works for all Customer |
| 749 | ; Domains due to the use of the DANE-EE(3) Certificate Usage. |
| 750 | ; |
| 751 | www1.example.com. IN CNAME w1.example.net. |
| 752 | _443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net. |
| 753 | _443._tcp.w1.example.net. IN TLSA DANE-EE SPKI SHA2-256 ( |
| 754 | 8A9A70596E869BED72C69D97A8895DFA |
| 755 | D86F300A343FECEFF19E89C27C896BC9 ) |
| 756 | |
| 757 | ; |
| 758 | ; A CA at the provider can also issue certificates for each Customer |
| 759 | ; Domain, and use the DANE-TA(2) Certificate Usage type to |
| 760 | ; indicate a trust anchor. |
| 761 | ; |
| 762 | www2.example.com. IN CNAME w2.example.net. |
| 763 | _443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net. |
| 764 | _443._tcp.w2.example.net. IN TLSA DANE-TA Cert SHA2-256 ( |
| 765 | C164B2C3F36D068D42A6138E446152F5 |
| 766 | 68615F28C69BD96A73E354CAC88ED00C ) |
| 767 | |
| 768 | With protocols that support explicit transport redirection via DNS MX |
| 769 | records, SRV records, or other similar records, the TLSA base domain |
| 770 | is based on the redirected transport end-point, rather than the |
| 771 | origin domain. With SMTP, for example, when an email service is |
| 772 | hosted by a Service Provider, the Customer Domain's MX hostnames will |
| 773 | point at the Service Provider's SMTP hosts. When the Customer |
| 774 | Domain's DNS zone is signed, the MX hostnames can be securely used as |
| 775 | the base domains for TLSA records that are published and managed by |
| 776 | the Service Provider. For example (without the required DNSSEC |
| 777 | information, such as record signatures): |
| 778 | |
| 779 | |
| 780 | |
| 781 | |
| 782 | |
| 783 | |
| 784 | Dukhovni & Hardaker Expires February 18, 2015 [Page 14] |
| 785 | \f |
| 786 | Internet-Draft DANE operations August 2014 |
| 787 | |
| 788 | |
| 789 | ; Hosted SMTP service |
| 790 | ; |
| 791 | example.com. IN MX 0 mx1.example.net. |
| 792 | example.com. IN MX 0 mx2.example.net. |
| 793 | _25._tcp.mx1.example.net. IN TLSA DANE-EE SPKI SHA2-256 ( |
| 794 | 8A9A70596E869BED72C69D97A8895DFA |
| 795 | D86F300A343FECEFF19E89C27C896BC9 ) |
| 796 | _25._tcp.mx2.example.net. IN TLSA DANE-EE SPKI SHA2-256 ( |
| 797 | C164B2C3F36D068D42A6138E446152F5 |
| 798 | 68615F28C69BD96A73E354CAC88ED00C ) |
| 799 | |
| 800 | If redirection to the Service Provider's domain (via MX or SRV |
| 801 | records or any similar mechanism) is not possible, and aliasing of |
| 802 | the TLSA record is not an option, then more complex coordination |
| 803 | between the Customer Domain and Service Provider will be required. |
| 804 | Either the Customer Domain periodically provides private keys and a |
| 805 | corresponding certificate chain to the Provider (after making |
| 806 | appropriate changes in its TLSA records), or the Service Provider |
| 807 | periodically generates the keys and certificates and must wait for |
| 808 | matching TLSA records to be published by its Customer Domains before |
| 809 | deploying newly generated keys and certificate chains. In Section 6 |
| 810 | below, we describe an approach that employs CNAME "chasing" to avoid |
| 811 | the difficulties of coordinating key management across organization |
| 812 | boundaries. |
| 813 | |
| 814 | For further information about combining DANE and SRV, please see |
| 815 | [I-D.ietf-dane-srv]. |
| 816 | |
| 817 | 6. TLSA Base Domain and CNAMEs |
| 818 | |
| 819 | When the application protocol does not support service location |
| 820 | indirection via MX, SRV or similar DNS records, the service may be |
| 821 | redirected via a CNAME. A CNAME is a more blunt instrument for this |
| 822 | purpose, since unlike an MX or SRV record, it remaps the entire |
| 823 | origin domain to the target domain for all protocols. |
| 824 | |
| 825 | The complexity of coordinating key management is largely eliminated |
| 826 | when DANE TLSA records are found in the Service Provider's domain, as |
| 827 | discussed in Section 5. Therefore, DANE TLS clients connecting to a |
| 828 | server whose domain name is a CNAME alias SHOULD follow the CNAME |
| 829 | hop-by-hop to its ultimate target host (noting at each step whether |
| 830 | the CNAME is DNSSEC-validated). If at each stage of CNAME expansion |
| 831 | the DNSSEC validation status is "secure", the final target name |
| 832 | SHOULD be the preferred base domain for TLSA lookups. |
| 833 | |
| 834 | Implementations failing to find a TLSA record using a base name of |
| 835 | the final target of a CNAME expansion SHOULD issue a TLSA query using |
| 836 | the original destination name. That is, the preferred TLSA base |
| 837 | |
| 838 | |
| 839 | |
| 840 | Dukhovni & Hardaker Expires February 18, 2015 [Page 15] |
| 841 | \f |
| 842 | Internet-Draft DANE operations August 2014 |
| 843 | |
| 844 | |
| 845 | domain should be derived from the fully expanded name, and failing |
| 846 | that should be the initial domain name. |
| 847 | |
| 848 | When the TLSA base domain is the result of "secure" CNAME expansion, |
| 849 | the resulting domain name MUST be used as the HostName in SNI, and |
| 850 | MUST be the primary reference identifier for peer certificate |
| 851 | matching with certificate usages other than DANE-EE(3). |
| 852 | |
| 853 | Protocol-specific TLSA specifications may provide additional guidance |
| 854 | or restrictions when following CNAME expansions. |
| 855 | |
| 856 | Though CNAMEs are illegal on the right hand side of most indirection |
| 857 | records, such as MX and SRV records, they are supported by some |
| 858 | implementations. For example, if the MX or SRV host is a CNAME |
| 859 | alias, some implementations may "chase" the CNAME. If they do, they |
| 860 | SHOULD use the target hostname as the preferred TLSA base domain as |
| 861 | described above (and if the TLSA records are found there, use the |
| 862 | CNAME expanded domain also in SNI and certificate name checks). |
| 863 | |
| 864 | 7. TLSA Publisher Requirements |
| 865 | |
| 866 | This section updates [RFC6698] by specifying a requirement on the |
| 867 | TLSA Publisher to ensure that each combination of Certificate Usage, |
| 868 | selector and matching type in the server's TLSA RRset MUST include at |
| 869 | least one record that matches the server's current certificate chain. |
| 870 | TLSA records that match recently retired or yet to be deployed |
| 871 | certificate chains will be present during key rollover. Such past or |
| 872 | future records must never be the only records published for any given |
| 873 | combination of usage, selector and matching type. We describe a TLSA |
| 874 | record update algorithm that ensures this requirement is met. |
| 875 | |
| 876 | While a server is to be considered authenticated when its certificate |
| 877 | chain is matched by any of the published TLSA records, not all |
| 878 | clients support all combinations of TLSA record parameters. Some |
| 879 | clients may not support some digest algorithms, others may either not |
| 880 | support, or may exclusively support, the PKIX Certificate Usages. |
| 881 | Some clients may prefer to negotiate [I-D.ietf-tls-oob-pubkey] raw |
| 882 | public keys, which are only compatible with TLSA records whose |
| 883 | Certificate Usage is DANE-EE(3) with selector SPKI(1). |
| 884 | |
| 885 | |
| 886 | |
| 887 | |
| 888 | |
| 889 | |
| 890 | |
| 891 | |
| 892 | |
| 893 | |
| 894 | |
| 895 | |
| 896 | Dukhovni & Hardaker Expires February 18, 2015 [Page 16] |
| 897 | \f |
| 898 | Internet-Draft DANE operations August 2014 |
| 899 | |
| 900 | |
| 901 | A consequence of the above uncertainty as to which TLSA parameters |
| 902 | are supported by any given client is that servers need to ensure that |
| 903 | each and every parameter combination that appears in the TLSA RRset |
| 904 | is, on its own, sufficient to match the server's current certificate |
| 905 | chain. In particular, when deploying new keys or new parameter |
| 906 | combinations some care is required to not generate parameter |
| 907 | combinations that only match past or future certificate chains (or |
| 908 | raw public keys). The rest of this section explains how to update |
| 909 | the TLSA RRset in a manner that ensures the above requirement is met. |
| 910 | |
| 911 | 7.1. Key rollover with fixed TLSA Parameters |
| 912 | |
| 913 | The simplest case is key rollover while retaining the same set of |
| 914 | published parameter combinations. In this case, TLSA records |
| 915 | matching the existing server certificate chain (or raw public keys) |
| 916 | are first augmented with corresponding records matching the future |
| 917 | keys, at least two TTLs or longer before the the new chain is |
| 918 | deployed. This allows the obsolete RRset to age out of client caches |
| 919 | before the new chain is used in TLS handshakes. Once sufficient time |
| 920 | has elapsed and all clients performing DNS lookups are retrieving the |
| 921 | updated TLSA records, the server administrator may deploy the new |
| 922 | certificate chain, verify that it works, and then remove any obsolete |
| 923 | records matching the no longer active chain: |
| 924 | |
| 925 | ; The initial TLSA RRset |
| 926 | ; |
| 927 | _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... |
| 928 | |
| 929 | ; The transitional TLSA RRset published at least 2*TTL seconds |
| 930 | ; before the actual key change |
| 931 | ; |
| 932 | _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... |
| 933 | _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... |
| 934 | |
| 935 | ; The final TLSA RRset after the key change |
| 936 | ; |
| 937 | _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... |
| 938 | |
| 939 | The next case to consider is adding or switching to a new combination |
| 940 | of TLSA parameters. In this case publish the new parameter |
| 941 | combinations for the server's existing certificate chain first, and |
| 942 | only then deploy new keys if desired: |
| 943 | |
| 944 | |
| 945 | |
| 946 | |
| 947 | |
| 948 | |
| 949 | |
| 950 | |
| 951 | |
| 952 | Dukhovni & Hardaker Expires February 18, 2015 [Page 17] |
| 953 | \f |
| 954 | Internet-Draft DANE operations August 2014 |
| 955 | |
| 956 | |
| 957 | ; Initial TLSA RRset |
| 958 | ; |
| 959 | _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46... |
| 960 | |
| 961 | ; New TLSA RRset, same key re-published as DANE-EE(3) |
| 962 | ; |
| 963 | _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... |
| 964 | |
| 965 | 7.2. Switching to DANE-TA from DANE-EE |
| 966 | |
| 967 | A more complex involves switching to a trust-anchor or PKIX usage |
| 968 | from a chain that is either self-signed, or issued by a private CA |
| 969 | and thus not compatible with PKIX. Here the process is to first add |
| 970 | TLSA records matching the future chain that is issued by the desired |
| 971 | future CA (private or PKIX), but initially with the same parameters |
| 972 | as the legacy chain. Then, after deploying the new keys, switch to |
| 973 | the new TLSA parameter combination. |
| 974 | |
| 975 | ; The initial TLSA RRset |
| 976 | ; |
| 977 | _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... |
| 978 | |
| 979 | ; A transitional TLSA RRset, published at least 2*TTL before the |
| 980 | ; actual key change. The new keys are issued by a DANE-TA(2) CA, |
| 981 | ; but for now specified via a DANE-EE(3) association. |
| 982 | ; |
| 983 | _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... |
| 984 | _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... |
| 985 | |
| 986 | ; The final TLSA RRset after the key change. Now that the old |
| 987 | ; self-signed EE keys are not an impediment, specify the issuing |
| 988 | ; TA of the new keys. |
| 989 | ; |
| 990 | _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d... |
| 991 | |
| 992 | 7.3. Switching to New TLSA Parameters |
| 993 | |
| 994 | When employing a new digest algorithm in the TLSA RRset, for |
| 995 | compatibility with digest agility specified in Section 8 below, |
| 996 | administrators should publish the new digest algorithm with each |
| 997 | combinations of Certificate Usage and selector for each associated |
| 998 | key or chain used with any other digest algorithm. When removing an |
| 999 | algorithm, remove it entirely. Each digest algorithm employed should |
| 1000 | match the same set of chains (or raw public keys). |
| 1001 | |
| 1002 | |
| 1003 | |
| 1004 | |
| 1005 | |
| 1006 | |
| 1007 | |
| 1008 | Dukhovni & Hardaker Expires February 18, 2015 [Page 18] |
| 1009 | \f |
| 1010 | Internet-Draft DANE operations August 2014 |
| 1011 | |
| 1012 | |
| 1013 | ; The initial TLSA RRset with EE SHA2-256 associations for two keys. |
| 1014 | ; |
| 1015 | _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... |
| 1016 | _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... |
| 1017 | |
| 1018 | ; The new TLSA RRset also with SHA2-512 associations for each key |
| 1019 | ; |
| 1020 | _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... |
| 1021 | _443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc... |
| 1022 | _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... |
| 1023 | _443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714... |
| 1024 | |
| 1025 | 7.4. TLSA Publisher Requirements Summary |
| 1026 | |
| 1027 | In summary, server operators updating TLSA records should make one |
| 1028 | change at a time. The individual safe changes are: |
| 1029 | |
| 1030 | o Pre-publish new certificate associations that employ the same TLSA |
| 1031 | parameters (usage, selector and matching type) as existing TLSA |
| 1032 | records, but match certificate chains that will be deployed in the |
| 1033 | near future. Wait for stale TLSA RRsets to expire from DNS caches |
| 1034 | before configuring servers to use the new certificate chain. |
| 1035 | |
| 1036 | o Remove TLSA records matching no longer deployed certificate |
| 1037 | chains. |
| 1038 | |
| 1039 | o Extend the TLSA RRset with a new combination of parameters (usage, |
| 1040 | selector and matching type) that is used to generate matching |
| 1041 | associations for all certificate chains that are published with |
| 1042 | some other parameter combination. |
| 1043 | |
| 1044 | The above steps are intended to ensure that at all times and for each |
| 1045 | combination of usage, selector and matching type at least one TLSA |
| 1046 | record corresponds to the server's current certificate chain. No |
| 1047 | combination of Certificate Usage, selector and matching type in a |
| 1048 | server's TLSA RRset should ever match only some combination of future |
| 1049 | or past certificate chains. As a result, no matter what combinations |
| 1050 | of usage, selector and matching type may be supported by a given |
| 1051 | client, they will be sufficient to authenticate the server. |
| 1052 | |
| 1053 | 8. Digest Algorithm Agility |
| 1054 | |
| 1055 | |
| 1056 | |
| 1057 | |
| 1058 | |
| 1059 | |
| 1060 | |
| 1061 | |
| 1062 | |
| 1063 | |
| 1064 | Dukhovni & Hardaker Expires February 18, 2015 [Page 19] |
| 1065 | \f |
| 1066 | Internet-Draft DANE operations August 2014 |
| 1067 | |
| 1068 | |
| 1069 | While [RFC6698] specifies multiple digest algorithms, it does not |
| 1070 | specify a protocol by which the TLS client and TLSA record publisher |
| 1071 | can agree on the strongest shared algorithm. Such a protocol would |
| 1072 | allow the client and server to avoid exposure to any deprecated |
| 1073 | weaker algorithms that are published for compatibility with less |
| 1074 | capable clients, but should be ignored when possible. We specify |
| 1075 | such a protocol below. |
| 1076 | |
| 1077 | Suppose that a DANE TLS client authenticating a TLS server considers |
| 1078 | digest algorithm "BetterAlg" stronger than digest algorithm |
| 1079 | "WorseAlg". Suppose further that a server's TLSA RRset contains some |
| 1080 | records with "BetterAlg" as the digest algorithm. Suppose also that |
| 1081 | the server adheres to the requirements of Section 7 and ensures that |
| 1082 | each combination of TLSA parameters contains at least one record that |
| 1083 | matches the server's current certificate chain (or raw public keys). |
| 1084 | Under the above assumptions the client can safely ignore TLSA records |
| 1085 | with the weaker algorithm "WorseAlg", because it suffices to only |
| 1086 | check the records with the stronger algorithm "BetterAlg". |
| 1087 | |
| 1088 | To make digest algorithm agility possible, all published TLSA RRsets |
| 1089 | for use with DANE TLS MUST conform to the requirements of Section 7. |
| 1090 | With servers publishing compliant TLSA RRsets, TLS clients can, for |
| 1091 | each combination of usage and selector, ignore all digest records |
| 1092 | except those that employ their notion of the strongest digest |
| 1093 | algorithm. (The server should only publish algorithms it deems |
| 1094 | acceptable at all.) The ordering of digest algorithms by strength is |
| 1095 | not specified in advance; it is entirely up to the TLS client. TLS |
| 1096 | client implementations SHOULD make the digest algorithm preference |
| 1097 | ordering a configurable option. |
| 1098 | |
| 1099 | Note, TLSA records with a matching type of Full(0) that publish an |
| 1100 | entire certificate or public key object play no role in digest |
| 1101 | algorithm agility. They neither trump the processing of records that |
| 1102 | employ digests, nor are they ignored in the presence of any records |
| 1103 | with a digest (i.e. non-zero) matching type. |
| 1104 | |
| 1105 | TLS clients SHOULD use digest algorithm agility when processing the |
| 1106 | DANE TLSA records of an TLS server. Algorithm agility is to be |
| 1107 | applied after first discarding any unusable or malformed records |
| 1108 | (unsupported digest algorithm, or incorrect digest length). Thus, |
| 1109 | for each usage and selector, the client SHOULD process only any |
| 1110 | usable records with a matching type of Full(0) and the usable records |
| 1111 | whose digest algorithm is considered by the client to be the |
| 1112 | strongest among usable records with the given usage and selector. |
| 1113 | |
| 1114 | 9. General DANE Guidelines |
| 1115 | |
| 1116 | |
| 1117 | |
| 1118 | |
| 1119 | |
| 1120 | Dukhovni & Hardaker Expires February 18, 2015 [Page 20] |
| 1121 | \f |
| 1122 | Internet-Draft DANE operations August 2014 |
| 1123 | |
| 1124 | |
| 1125 | These guidelines provide guidance for using or designing protocols |
| 1126 | for DANE. |
| 1127 | |
| 1128 | 9.1. DANE DNS Record Size Guidelines |
| 1129 | |
| 1130 | Selecting a combination of TLSA parameters to use requires careful |
| 1131 | thought. One important consideration to take into account is the |
| 1132 | size of the resulting TLSA record after its parameters are selected. |
| 1133 | |
| 1134 | 9.1.1. UDP and TCP Considerations |
| 1135 | |
| 1136 | Deployments SHOULD avoid TLSA record sizes that cause UDP |
| 1137 | fragmentation. |
| 1138 | |
| 1139 | Although DNS over TCP would provide the ability to more easily |
| 1140 | transfer larger DNS records between clients and servers, it is not |
| 1141 | universally deployed and is still prohibited by some firewalls. |
| 1142 | Clients that request DNS records via UDP typically only use TCP upon |
| 1143 | receipt of a truncated response in the DNS response message sent over |
| 1144 | UDP. Setting the TC bit alone will be insufficient if the response |
| 1145 | containing the TC bit is itself fragmented. |
| 1146 | |
| 1147 | 9.1.2. Packet Size Considerations for TLSA Parameters |
| 1148 | |
| 1149 | Server operators SHOULD NOT publish TLSA records using both a TLSA |
| 1150 | Selector of Cert(0) and a TLSA Matching Type of Full(0), as even a |
| 1151 | single certificate is generally too large to be reliably delivered |
| 1152 | via DNS over UDP. Furthermore, two TLSA records containing full |
| 1153 | certificates will need to be published simultaneously during a |
| 1154 | certificate rollover, as discussed in Section 7.1. |
| 1155 | |
| 1156 | While TLSA records using a TLSA Selector of SPKI(1) and a TLSA |
| 1157 | Matching Type of Full(0) (which publish the bare public keys without |
| 1158 | the overhead of a containing X.509 certificate) are generally more |
| 1159 | compact, these too should be used with caution as they are still |
| 1160 | larger than necessary. Rather, servers SHOULD publish digest-based |
| 1161 | TLSA Matching Types in their TLSA records. The complete |
| 1162 | corresponding certificate should, instead, be transmitted to the |
| 1163 | client in-band during the TLS handshake, which can be easily verified |
| 1164 | using the digest value. |
| 1165 | |
| 1166 | In summary, the use of a TLSA Matching Type of Full(0) is NOT |
| 1167 | RECOMMENDED and the use of a digest-based matching type, such as |
| 1168 | SHA2-256(1) SHOULD be used. |
| 1169 | |
| 1170 | 9.2. Certificate Name Check Conventions |
| 1171 | |
| 1172 | |
| 1173 | |
| 1174 | |
| 1175 | |
| 1176 | Dukhovni & Hardaker Expires February 18, 2015 [Page 21] |
| 1177 | \f |
| 1178 | Internet-Draft DANE operations August 2014 |
| 1179 | |
| 1180 | |
| 1181 | Certificates presented by a TLS server will generally contain a |
| 1182 | subjectAltName (SAN) extension or a Common Name (CN) element within |
| 1183 | the subject distinguished name (DN). The TLS server's DNS domain |
| 1184 | name is normally published within these elements, ideally within the |
| 1185 | subjectAltName extension. (The use of the CN field for this purpose |
| 1186 | is deprecated.) |
| 1187 | |
| 1188 | When a server hosts multiple domains at the same transport endpoint, |
| 1189 | the server's ability to respond with the right certificate chain is |
| 1190 | predicated on correct SNI information from the client. DANE clients |
| 1191 | MUST send the SNI extension with a HostName value of the base domain |
| 1192 | of the TLSA RRset. |
| 1193 | |
| 1194 | Except with TLSA Certificate Usage DANE-EE(3), where name checks are |
| 1195 | not applicable (see Section 4.1), DANE clients MUST verify that the |
| 1196 | client has reached the correct server by checking that the server |
| 1197 | name is listed in the server certificate's SAN or CN. The server |
| 1198 | name used for this comparison SHOULD be the base domain of the TLSA |
| 1199 | RRset. Additional acceptable names may be specified by protocol- |
| 1200 | specific DANE standards. For example, with SMTP both the destination |
| 1201 | domain name and the MX host name are acceptable names to be found in |
| 1202 | the server certificate (see [I-D.ietf-dane-smtp-with-dane]). |
| 1203 | |
| 1204 | It is the responsibility of the service operator, in coordination |
| 1205 | with the TLSA Publisher, to ensure that at least one of the TLSA |
| 1206 | records published for the service will match the server's certificate |
| 1207 | chain (either the default chain or the certificate that was selected |
| 1208 | based on the SNI information provided by the client). |
| 1209 | |
| 1210 | Given the DNSSEC validated DNS records below: |
| 1211 | |
| 1212 | example.com. IN MX 0 mail.example.com. |
| 1213 | mail.example.com. IN A 192.0.2.1 |
| 1214 | _25._tcp.mail.example.com. IN TLSA DANE-TA Cert SHA2-256 ( |
| 1215 | E8B54E0B4BAA815B06D3462D65FBC7C0 |
| 1216 | CF556ECCF9F5303EBFBB77D022F834C0 ) |
| 1217 | |
| 1218 | The TLSA base domain is "mail.example.com" and is required to be the |
| 1219 | HostName in the client's SNI extension. The server certificate chain |
| 1220 | is required to be be signed by a trust anchor with the above |
| 1221 | certificate SHA2-256 digest. Finally, one of the DNS names in the |
| 1222 | server certificate is required to be be either "mail.example.com" or |
| 1223 | "example.com" (this additional name is a concession to compatibility |
| 1224 | with prior practice, see [I-D.ietf-dane-smtp-with-dane] for details). |
| 1225 | |
| 1226 | The semantics of wildcards in server certificates are left to |
| 1227 | individual application protocol specifications. |
| 1228 | |
| 1229 | |
| 1230 | |
| 1231 | |
| 1232 | Dukhovni & Hardaker Expires February 18, 2015 [Page 22] |
| 1233 | \f |
| 1234 | Internet-Draft DANE operations August 2014 |
| 1235 | |
| 1236 | |
| 1237 | 9.3. Design Considerations for Protocols Using DANE |
| 1238 | |
| 1239 | When a TLS client goes to the trouble of authenticating a certificate |
| 1240 | chain presented by a TLS server, it will typically not continue to |
| 1241 | use that server in the event of authentication failure, or else |
| 1242 | authentication serves no purpose. Some clients may, at times, |
| 1243 | operate in an "audit" mode, where authentication failure is reported |
| 1244 | to the user or in logs as a potential problem, but the connection |
| 1245 | proceeds despite the failure. Nevertheless servers publishing TLSA |
| 1246 | records MUST be configured to allow correctly configured clients to |
| 1247 | successfully authenticate their TLS certificate chains. |
| 1248 | |
| 1249 | A service with DNSSEC-validated TLSA records implicitly promises TLS |
| 1250 | support. When all the TLSA records for a service are found |
| 1251 | "unusable", due to unsupported parameter combinations or malformed |
| 1252 | associated data, DANE clients cannot authenticate the service |
| 1253 | certificate chain. When authenticated TLS is dictated by the |
| 1254 | application, the client SHOULD NOT connect to the associated server. |
| 1255 | If, on the other hand, the use of TLS is "opportunistic", then the |
| 1256 | client SHOULD generally use the server via an unauthenticated TLS |
| 1257 | connection, but if TLS encryption cannot be established, the client |
| 1258 | MUST NOT use the server. Standards for DANE specific to the |
| 1259 | particular application protocol may modify the above requirements, as |
| 1260 | appropriate, to specify whether the connection should be established |
| 1261 | anyway without relying on TLS security, with only encryption but not |
| 1262 | authentication, or whether to refuse to connect entirely. |
| 1263 | Application protocols need to specify when to prioritize security |
| 1264 | over the ability to connect under adverse conditions. |
| 1265 | |
| 1266 | 9.3.1. Design Considerations for non-PKIX Protocols |
| 1267 | |
| 1268 | For some application protocols (such as SMTP to MX with opportunistic |
| 1269 | TLS), the existing public CA PKI is not a viable alternative to DANE. |
| 1270 | For these (non-PKIX) protocols, new DANE standards SHOULD NOT suggest |
| 1271 | publishing TLSA records with TLSA Certificate Usage PKIX-TA(0) or |
| 1272 | PKIX-EE(1), as TLS clients cannot be expected to perform [RFC5280] |
| 1273 | PKIX validation or [RFC6125] identity verification. |
| 1274 | |
| 1275 | Protocols designed for non-PKIX use SHOULD choose to treat any TLSA |
| 1276 | records with TLSA Certificate Usage PKIX-TA(0) or PKIX-EE(1) as |
| 1277 | unusable. After verifying that the only available TLSA Certificate |
| 1278 | Usage types are PKIX-TA(0) or PKIX-EE(1), protocol specifications MAY |
| 1279 | instruct clients to either refuse to initiate a connection or to |
| 1280 | connect via unauthenticated TLS if no alternative authentication |
| 1281 | mechanisms are available. |
| 1282 | |
| 1283 | 10. Interaction with Certificate Transparency |
| 1284 | |
| 1285 | |
| 1286 | |
| 1287 | |
| 1288 | Dukhovni & Hardaker Expires February 18, 2015 [Page 23] |
| 1289 | \f |
| 1290 | Internet-Draft DANE operations August 2014 |
| 1291 | |
| 1292 | |
| 1293 | Certificate Transparency (CT) [RFC6962] defines an experimental |
| 1294 | approach to mitigate the risk of rogue or compromised public CAs |
| 1295 | issuing unauthorized certificates. This section clarifies the |
| 1296 | interaction of CT and DANE. CT is an experimental protocol and |
| 1297 | auditing system that applies only to public CAs, and only when they |
| 1298 | are free to issue unauthorized certificates for a domain. If the CA |
| 1299 | is not a public CA, or a DANE-EE(3) TLSA RR directly specifies the |
| 1300 | end entity certificate, there is no role for CT, and clients need not |
| 1301 | apply CT checks. |
| 1302 | |
| 1303 | When a server is authenticated via a DANE TLSA RR with TLSA |
| 1304 | Certificate Usage DANE-EE(3), the domain owner has directly specified |
| 1305 | the certificate associated with the given service without reference |
| 1306 | to any PKIX certification authority. Therefore, when a TLS client |
| 1307 | authenticates the TLS server via a TLSA certificate association with |
| 1308 | usage DANE-EE(3), CT checks SHOULD NOT be performed. Publication of |
| 1309 | the server certificate or public key (digest) in a TLSA record in a |
| 1310 | DNSSEC signed zone by the domain owner assures the TLS client that |
| 1311 | the certificate is not an unauthorized certificate issued by a rogue |
| 1312 | CA without the domain owner's consent. |
| 1313 | |
| 1314 | When a server is authenticated via a DANE TLSA RR with TLSA usage |
| 1315 | DANE-TA(2) and the server certificate does not chain to a known |
| 1316 | public root CA, CT cannot apply (CT logs only accept chains that |
| 1317 | start with a known, public root). Since TLSA Certificate Usage DANE- |
| 1318 | TA(2) is generally intended to support non-PKIX trust anchors, TLS |
| 1319 | clients SHOULD NOT perform CT checks with usage DANE-TA(2) using |
| 1320 | unknown root CAs. |
| 1321 | |
| 1322 | A server operator who wants clients to perform CT checks should |
| 1323 | publish TLSA RRs with usage PKIX-TA(0) or PKIX-EE(1). |
| 1324 | |
| 1325 | 11. Note on DNSSEC Security |
| 1326 | |
| 1327 | Clearly the security of the DANE TLSA PKI rests on the security of |
| 1328 | the underlying DNSSEC infrastructure. While this memo is not a guide |
| 1329 | to DNSSEC security, a few comments may be helpful to TLSA |
| 1330 | implementers. |
| 1331 | |
| 1332 | With the existing public CA PKI, name constraints are rarely used, |
| 1333 | and a public root CA can issue certificates for any domain of its |
| 1334 | choice. With DNSSEC, under the Registry/Registrar/Registrant model, |
| 1335 | the situation is different: only the registrar of record can update a |
| 1336 | domain's DS record in the registry parent zone (in some cases, |
| 1337 | however, the registry is the sole registrar). With many gTLDs, for |
| 1338 | which multiple registrars compete to provide domains in a single |
| 1339 | registry, it is important to make sure that rogue registrars cannot |
| 1340 | easily initiate an unauthorized domain transfer, and thus take over |
| 1341 | |
| 1342 | |
| 1343 | |
| 1344 | Dukhovni & Hardaker Expires February 18, 2015 [Page 24] |
| 1345 | \f |
| 1346 | Internet-Draft DANE operations August 2014 |
| 1347 | |
| 1348 | |
| 1349 | DNSSEC for the domain. DNS Operators SHOULD use a registrar lock of |
| 1350 | their domains to offer some protection against this possibility. |
| 1351 | |
| 1352 | When the registrar is also the DNS operator for the domain, one needs |
| 1353 | to consider whether the registrar will allow orderly migration of the |
| 1354 | domain to another registrar or DNS operator in a way that will |
| 1355 | maintain DNSSEC integrity. TLSA Publishers SHOULD ensure their |
| 1356 | registrar publishes a suitable domain transfer policy. |
| 1357 | |
| 1358 | DNSSEC signed RRsets cannot be securely revoked before they expire. |
| 1359 | Operators should plan accordingly and not generate signatures with |
| 1360 | excessively long duration periods. For domains publishing high-value |
| 1361 | keys, a signature lifetime of a few days is reasonable, and the zone |
| 1362 | should be resigned daily. For domains with less critical data, a |
| 1363 | reasonable signature lifetime is a couple of weeks to a month, and |
| 1364 | the zone should be resigned weekly. Monitoring of the signature |
| 1365 | lifetime is important. If the zone is not resigned in a timely |
| 1366 | manner, one risks a major outage and the entire domain will become |
| 1367 | bogus. |
| 1368 | |
| 1369 | 12. Summary of Updates to RFC6698 |
| 1370 | |
| 1371 | Authors note: is this section needed? Or is it sufficiently clear |
| 1372 | above that we don't need to restate things here? |
| 1373 | |
| 1374 | o In Section 3 we update [RFC6698] to specify a requirement for |
| 1375 | clients to support at least TLS 1.0, and to support SNI. |
| 1376 | |
| 1377 | o In Section 4.1 we update [RFC6698] to specify peer identity |
| 1378 | matching and certificate validity interval based solely on the |
| 1379 | basis of the TLSA RRset. We also specify DANE authentication of |
| 1380 | raw public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with |
| 1381 | Certificate Usage DANE-EE(3) and selector SPKI(1). |
| 1382 | |
| 1383 | o In Section 4.2 we update [RFC6698] to require that servers |
| 1384 | publishing digest TLSA records with a usage of DANE-TA(2) MUST |
| 1385 | include the trust-anchor certificate in their TLS server |
| 1386 | certificate message. This extends to the case of "2 1 0" TLSA |
| 1387 | records which publish a full public key. |
| 1388 | |
| 1389 | o In Section 4.3 and Section 4.4, we explain that PKIX-EE(1) and |
| 1390 | PKIX-TA(0) are generally NOT RECOMMENDED. With usage PKIX-TA(0) |
| 1391 | we note that clients may need to processes extended trust chains |
| 1392 | beyond the first trusted issuer, when that issuer is not self- |
| 1393 | signed. |
| 1394 | |
| 1395 | |
| 1396 | |
| 1397 | |
| 1398 | |
| 1399 | |
| 1400 | Dukhovni & Hardaker Expires February 18, 2015 [Page 25] |
| 1401 | \f |
| 1402 | Internet-Draft DANE operations August 2014 |
| 1403 | |
| 1404 | |
| 1405 | o In Section 6, we recommend that DANE application protocols specify |
| 1406 | that when possible securely CNAME expanded names be used to derive |
| 1407 | the TLSA base domain. |
| 1408 | |
| 1409 | o In Section 7, we specify a strategy for managing TLSA records that |
| 1410 | interoperates with DANE clients regardless of what subset of the |
| 1411 | possible TLSA record types (combinations of TLSA parameters) is |
| 1412 | supported by the client. |
| 1413 | |
| 1414 | o In Section 8, we propose a digest algorithm agility protocol. |
| 1415 | [Note: This section does not yet represent the rough consensus of |
| 1416 | the DANE working group and requires further discussion. Perhaps |
| 1417 | this belongs in a separate document.] |
| 1418 | |
| 1419 | o In Section 9.1 we recommend against the use of Full(0) TLSA |
| 1420 | records, as digest records are generally much more compact. |
| 1421 | |
| 1422 | 13. Security Considerations |
| 1423 | |
| 1424 | Application protocols that cannot make use of the existing public CA |
| 1425 | PKI (so called non-PKIX protocols), may choose not to implement |
| 1426 | certain PKIX-dependent TLSA record types defined in [RFC6698]. If |
| 1427 | such records are published despite not being supported by the |
| 1428 | application protocol, they are treated as "unusable". When TLS is |
| 1429 | opportunistic, the client may proceed to use the server with |
| 1430 | mandatory unauthenticated TLS. This is stronger than opportunistic |
| 1431 | TLS without DANE, since in that case the client may also proceed with |
| 1432 | a plaintext connection. When TLS is not opportunistic, the client |
| 1433 | MUST NOT connect to the server. |
| 1434 | |
| 1435 | Therefore, when TLSA records are used with protocols where PKIX does |
| 1436 | not apply, the recommended policy is for servers to not publish PKIX- |
| 1437 | dependent TLSA records, and for opportunistic TLS clients to use them |
| 1438 | to enforce the use of (albeit unauthenticated) TLS, but otherwise |
| 1439 | treat them as unusable. Of course, when PKIX validation is supported |
| 1440 | by the application protocol, clients SHOULD perform PKIX validation |
| 1441 | per [RFC6698]. |
| 1442 | |
| 1443 | 14. IANA Considerations |
| 1444 | |
| 1445 | This specification requires no support from IANA. |
| 1446 | |
| 1447 | 15. Acknowledgements |
| 1448 | |
| 1449 | The authors would like to thank Phil Pennock for his comments and |
| 1450 | advice on this document. |
| 1451 | |
| 1452 | |
| 1453 | |
| 1454 | |
| 1455 | |
| 1456 | Dukhovni & Hardaker Expires February 18, 2015 [Page 26] |
| 1457 | \f |
| 1458 | Internet-Draft DANE operations August 2014 |
| 1459 | |
| 1460 | |
| 1461 | Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded |
| 1462 | me into participating in DANE working group discussions. Thanks to |
| 1463 | Paul Hoffman who motivated me to produce this memo and provided |
| 1464 | feedback on early drafts. Thanks also to Samuel Dukhovni for |
| 1465 | editorial assistance. |
| 1466 | |
| 1467 | 16. References |
| 1468 | |
| 1469 | 16.1. Normative References |
| 1470 | |
| 1471 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| 1472 | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| 1473 | |
| 1474 | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
| 1475 | Rose, "DNS Security Introduction and Requirements", RFC |
| 1476 | 4033, March 2005. |
| 1477 | |
| 1478 | [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
| 1479 | Rose, "Resource Records for the DNS Security Extensions", |
| 1480 | RFC 4034, March 2005. |
| 1481 | |
| 1482 | [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
| 1483 | Rose, "Protocol Modifications for the DNS Security |
| 1484 | Extensions", RFC 4035, March 2005. |
| 1485 | |
| 1486 | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security |
| 1487 | (TLS) Protocol Version 1.2", RFC 5246, August 2008. |
| 1488 | |
| 1489 | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., |
| 1490 | Housley, R., and W. Polk, "Internet X.509 Public Key |
| 1491 | Infrastructure Certificate and Certificate Revocation List |
| 1492 | (CRL) Profile", RFC 5280, May 2008. |
| 1493 | |
| 1494 | [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: |
| 1495 | Extension Definitions", RFC 6066, January 2011. |
| 1496 | |
| 1497 | [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and |
| 1498 | Verification of Domain-Based Application Service Identity |
| 1499 | within Internet Public Key Infrastructure Using X.509 |
| 1500 | (PKIX) Certificates in the Context of Transport Layer |
| 1501 | Security (TLS)", RFC 6125, March 2011. |
| 1502 | |
| 1503 | [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer |
| 1504 | Security Version 1.2", RFC 6347, January 2012. |
| 1505 | |
| 1506 | [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication |
| 1507 | of Named Entities (DANE) Transport Layer Security (TLS) |
| 1508 | Protocol: TLSA", RFC 6698, August 2012. |
| 1509 | |
| 1510 | |
| 1511 | |
| 1512 | Dukhovni & Hardaker Expires February 18, 2015 [Page 27] |
| 1513 | \f |
| 1514 | Internet-Draft DANE operations August 2014 |
| 1515 | |
| 1516 | |
| 1517 | [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify |
| 1518 | Conversations about DNS-Based Authentication of Named |
| 1519 | Entities (DANE)", RFC 7218, April 2014. |
| 1520 | |
| 1521 | 16.2. Informative References |
| 1522 | |
| 1523 | [I-D.dukhovni-opportunistic-security] |
| 1524 | Dukhovni, V., "Opportunistic Security: Some Protection |
| 1525 | Most of the Time", draft-dukhovni-opportunistic- |
| 1526 | security-03 (work in progress), August 2014. |
| 1527 | |
| 1528 | [I-D.ietf-dane-smtp-with-dane] |
| 1529 | Dukhovni, V. and W. Hardaker, "SMTP security via |
| 1530 | opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-11 |
| 1531 | (work in progress), August 2014. |
| 1532 | |
| 1533 | [I-D.ietf-dane-srv] |
| 1534 | Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- |
| 1535 | Based Authentication of Named Entities (DANE) TLSA Records |
| 1536 | with SRV Records", draft-ietf-dane-srv-07 (work in |
| 1537 | progress), July 2014. |
| 1538 | |
| 1539 | [I-D.ietf-tls-oob-pubkey] |
| 1540 | Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and |
| 1541 | T. Kivinen, "Using Raw Public Keys in Transport Layer |
| 1542 | Security (TLS) and Datagram Transport Layer Security |
| 1543 | (DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress), |
| 1544 | January 2014. |
| 1545 | |
| 1546 | [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate |
| 1547 | Transparency", RFC 6962, June 2013. |
| 1548 | |
| 1549 | Authors' Addresses |
| 1550 | |
| 1551 | Viktor Dukhovni |
| 1552 | Unaffiliated |
| 1553 | |
| 1554 | Email: ietf-dane@dukhovni.org |
| 1555 | |
| 1556 | |
| 1557 | Wes Hardaker |
| 1558 | Parsons |
| 1559 | P.O. Box 382 |
| 1560 | Davis, CA 95617 |
| 1561 | US |
| 1562 | |
| 1563 | Email: ietf@hardakers.net |
| 1564 | |
| 1565 | |
| 1566 | |
| 1567 | |
| 1568 | Dukhovni & Hardaker Expires February 18, 2015 [Page 28] |