| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | Internet Engineering Task Force (IETF) P. Hoffman |
| 8 | Request for Comments: 6698 VPN Consortium |
| 9 | Category: Standards Track J. Schlyter |
| 10 | ISSN: 2070-1721 Kirei AB |
| 11 | August 2012 |
| 12 | |
| 13 | |
| 14 | The DNS-Based Authentication of Named Entities (DANE) |
| 15 | Transport Layer Security (TLS) Protocol: TLSA |
| 16 | |
| 17 | Abstract |
| 18 | |
| 19 | Encrypted communication on the Internet often uses Transport Layer |
| 20 | Security (TLS), which depends on third parties to certify the keys |
| 21 | used. This document improves on that situation by enabling the |
| 22 | administrators of domain names to specify the keys used in that |
| 23 | domain's TLS servers. This requires matching improvements in TLS |
| 24 | client software, but no change in TLS server software. |
| 25 | |
| 26 | Status of This Memo |
| 27 | |
| 28 | This is an Internet Standards Track document. |
| 29 | |
| 30 | This document is a product of the Internet Engineering Task Force |
| 31 | (IETF). It represents the consensus of the IETF community. It has |
| 32 | received public review and has been approved for publication by the |
| 33 | Internet Engineering Steering Group (IESG). Further information on |
| 34 | Internet Standards is available in Section 2 of RFC 5741. |
| 35 | |
| 36 | Information about the current status of this document, any errata, |
| 37 | and how to provide feedback on it may be obtained at |
| 38 | http://www.rfc-editor.org/info/rfc6698. |
| 39 | |
| 40 | Copyright Notice |
| 41 | |
| 42 | Copyright (c) 2012 IETF Trust and the persons identified as the |
| 43 | document authors. All rights reserved. |
| 44 | |
| 45 | This document is subject to BCP 78 and the IETF Trust's Legal |
| 46 | Provisions Relating to IETF Documents |
| 47 | (http://trustee.ietf.org/license-info) in effect on the date of |
| 48 | publication of this document. Please review these documents |
| 49 | carefully, as they describe your rights and restrictions with respect |
| 50 | to this document. Code Components extracted from this document must |
| 51 | include Simplified BSD License text as described in Section 4.e of |
| 52 | the Trust Legal Provisions and are provided without warranty as |
| 53 | described in the Simplified BSD License. |
| 54 | |
| 55 | |
| 56 | |
| 57 | |
| 58 | Hoffman & Schlyter Standards Track [Page 1] |
| 59 | \f |
| 60 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 61 | |
| 62 | |
| 63 | Table of Contents |
| 64 | |
| 65 | 1. Introduction ....................................................3 |
| 66 | 1.1. Background and Motivation ..................................3 |
| 67 | 1.2. Securing the Association of a Domain Name with a |
| 68 | Server's Certificate .......................................4 |
| 69 | 1.3. Method for Securing Certificate Associations ...............5 |
| 70 | 1.4. Terminology ................................................6 |
| 71 | 2. The TLSA Resource Record ........................................7 |
| 72 | 2.1. TLSA RDATA Wire Format .....................................7 |
| 73 | 2.1.1. The Certificate Usage Field .........................7 |
| 74 | 2.1.2. The Selector Field ..................................8 |
| 75 | 2.1.3. The Matching Type Field .............................9 |
| 76 | 2.1.4. The Certificate Association Data Field ..............9 |
| 77 | 2.2. TLSA RR Presentation Format ................................9 |
| 78 | 2.3. TLSA RR Examples ..........................................10 |
| 79 | 3. Domain Names for TLSA Certificate Associations .................10 |
| 80 | 4. Use of TLSA Records in TLS .....................................11 |
| 81 | 4.1. Usable Certificate Associations ...........................11 |
| 82 | 5. TLSA and DANE Use Cases and Requirements .......................13 |
| 83 | 6. Mandatory-to-Implement Features ................................15 |
| 84 | 7. IANA Considerations ............................................15 |
| 85 | 7.1. TLSA RRtype ...............................................15 |
| 86 | 7.2. TLSA Certificate Usages ...................................15 |
| 87 | 7.3. TLSA Selectors ............................................16 |
| 88 | 7.4. TLSA Matching Types .......................................16 |
| 89 | 8. Security Considerations ........................................16 |
| 90 | 8.1. Comparing DANE to Public CAs ..............................18 |
| 91 | 8.1.1. Risk of Key Compromise .............................19 |
| 92 | 8.1.2. Impact of Key Compromise ...........................20 |
| 93 | 8.1.3. Detection of Key Compromise ........................20 |
| 94 | 8.1.4. Spoofing Hostnames .................................20 |
| 95 | 8.2. DNS Caching ...............................................21 |
| 96 | 8.3. External DNSSEC Validators ................................21 |
| 97 | 9. Acknowledgements ...............................................22 |
| 98 | 10. References ....................................................22 |
| 99 | 10.1. Normative References .....................................22 |
| 100 | 10.2. Informative References ...................................23 |
| 101 | Appendix A. Operational Considerations for Deploying TLSA |
| 102 | Records ...............................................25 |
| 103 | A.1. Creating TLSA Records ......................................25 |
| 104 | A.1.1. Ambiguities and Corner Cases When TLS Clients |
| 105 | Build Trust Chains .....................................26 |
| 106 | A.1.2. Choosing a Selector Type ...............................26 |
| 107 | A.2. Provisioning TLSA Records in DNS ...........................28 |
| 108 | A.2.1. Provisioning TLSA Records with Aliases .................28 |
| 109 | A.3. Securing the Last Hop ......................................30 |
| 110 | A.4. Handling Certificate Rollover ..............................31 |
| 111 | |
| 112 | |
| 113 | |
| 114 | Hoffman & Schlyter Standards Track [Page 2] |
| 115 | \f |
| 116 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 117 | |
| 118 | |
| 119 | Appendix B. Pseudocode for Using TLSA .............................32 |
| 120 | B.1. Helper Functions ...........................................32 |
| 121 | B.2. Main TLSA Pseudocode .......................................33 |
| 122 | Appendix C. Examples ..............................................35 |
| 123 | |
| 124 | 1. Introduction |
| 125 | |
| 126 | 1.1. Background and Motivation |
| 127 | |
| 128 | Applications that communicate over the Internet often need to prevent |
| 129 | eavesdropping, tampering, or forgery of their communications. The |
| 130 | Transport Layer Security (TLS) protocol provides this kind of |
| 131 | communications security over the Internet, using channel encryption. |
| 132 | |
| 133 | The security properties of encryption systems depend strongly on the |
| 134 | keys that they use. If secret keys are revealed, or if public keys |
| 135 | can be replaced by fake keys (that is, a key not corresponding to the |
| 136 | entity identified in the certificate), these systems provide little |
| 137 | or no security. |
| 138 | |
| 139 | TLS uses certificates to bind keys and names. A certificate combines |
| 140 | a published key with other information such as the name of the |
| 141 | service that uses the key, and this combination is digitally signed |
| 142 | by another key. Having a key in a certificate is only helpful if one |
| 143 | trusts the other key that signed the certificate. If that other key |
| 144 | was itself revealed or substituted, then its signature is worthless |
| 145 | in proving anything about the first key. |
| 146 | |
| 147 | On the Internet, this problem has been solved for years by entities |
| 148 | called "Certification Authorities" (CAs). CAs protect their secret |
| 149 | key vigorously, while supplying their public key to the software |
| 150 | vendors who build TLS clients. They then sign certificates, and |
| 151 | supply those to TLS servers. TLS client software uses a set of these |
| 152 | CA keys as "trust anchors" to validate the signatures on certificates |
| 153 | that the client receives from TLS servers. Client software typically |
| 154 | allows any CA to usefully sign any other certificate. |
| 155 | |
| 156 | The public CA model upon which TLS has depended is fundamentally |
| 157 | vulnerable because it allows any of these CAs to issue a certificate |
| 158 | for any domain name. A single trusted CA that betrays its trust, |
| 159 | either voluntarily or by providing less-than-vigorous protection for |
| 160 | its secrets and capabilities, can undermine the security offered by |
| 161 | any certificates employed with TLS. This problem arises because a |
| 162 | compromised CA can issue a replacement certificate that contains a |
| 163 | fake key. Recent experiences with compromises of CAs or their |
| 164 | trusted partners have led to very serious security problems, such as |
| 165 | the governments of multiple countries attempting to wiretap and/or |
| 166 | subvert major TLS-protected web sites trusted by millions of users. |
| 167 | |
| 168 | |
| 169 | |
| 170 | Hoffman & Schlyter Standards Track [Page 3] |
| 171 | \f |
| 172 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 173 | |
| 174 | |
| 175 | The DNS Security Extensions (DNSSEC) provide a similar model that |
| 176 | involves trusted keys signing the information for untrusted keys. |
| 177 | However, DNSSEC provides three significant improvements. Keys are |
| 178 | tied to names in the Domain Name System (DNS), rather than to |
| 179 | arbitrary identifying strings; this is more convenient for Internet |
| 180 | protocols. Signed keys for any domain are accessible online through |
| 181 | a straightforward query using the standard DNSSEC protocol, so there |
| 182 | is no problem distributing the signed keys. Most significantly, the |
| 183 | keys associated with a domain name can only be signed by a key |
| 184 | associated with the parent of that domain name; for example, the keys |
| 185 | for "example.com" can only be signed by the keys for "com", and the |
| 186 | keys for "com" can only be signed by the DNS root. This prevents an |
| 187 | untrustworthy signer from compromising anyone's keys except those in |
| 188 | their own subdomains. Like TLS, DNSSEC relies on public keys that |
| 189 | come built into the DNSSEC client software, but these keys come only |
| 190 | from a single root domain rather than from a multiplicity of CAs. |
| 191 | |
| 192 | DNS-Based Authentication of Named Entities (DANE) offers the option |
| 193 | to use the DNSSEC infrastructure to store and sign keys and |
| 194 | certificates that are used by TLS. DANE is envisioned as a |
| 195 | preferable basis for binding public keys to DNS names, because the |
| 196 | entities that vouch for the binding of public key data to DNS names |
| 197 | are the same entities responsible for managing the DNS names in |
| 198 | question. While the resulting system still has residual security |
| 199 | vulnerabilities, it restricts the scope of assertions that can be |
| 200 | made by any entity, consistent with the naming scope imposed by the |
| 201 | DNS hierarchy. As a result, DANE embodies the security "principle of |
| 202 | least privilege" that is lacking in the current public CA model. |
| 203 | |
| 204 | 1.2. Securing the Association of a Domain Name with a Server's |
| 205 | Certificate |
| 206 | |
| 207 | A TLS client begins a connection by exchanging messages with a TLS |
| 208 | server. For many application protocols, it looks up the server's |
| 209 | name using the DNS to get an Internet Protocol (IP) address |
| 210 | associated with the name. It then begins a connection to a |
| 211 | particular port at that address, and sends an initial message there. |
| 212 | However, the client does not yet know whether an adversary is |
| 213 | intercepting and/or altering its communication before it reaches the |
| 214 | TLS server. It does not even know whether the real TLS server |
| 215 | associated with that domain name has ever received its initial |
| 216 | messages. |
| 217 | |
| 218 | The first response from the server in TLS may contain a certificate. |
| 219 | In order for the TLS client to authenticate that it is talking to the |
| 220 | expected TLS server, the client must validate that this certificate |
| 221 | is associated with the domain name used by the client to get to the |
| 222 | server. Currently, the client must extract the domain name from the |
| 223 | |
| 224 | |
| 225 | |
| 226 | Hoffman & Schlyter Standards Track [Page 4] |
| 227 | \f |
| 228 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 229 | |
| 230 | |
| 231 | certificate and must successfully validate the certificate, including |
| 232 | chaining to a trust anchor. |
| 233 | |
| 234 | There is a different way to authenticate the association of the |
| 235 | server's certificate with the intended domain name without trusting |
| 236 | an external CA. Given that the DNS administrator for a domain name |
| 237 | is authorized to give identifying information about the zone, it |
| 238 | makes sense to allow that administrator to also make an authoritative |
| 239 | binding between the domain name and a certificate that might be used |
| 240 | by a host at that domain name. The easiest way to do this is to use |
| 241 | the DNS, securing the binding with DNSSEC. |
| 242 | |
| 243 | There are many use cases for such functionality. [RFC6394] lists the |
| 244 | ones to which the DNS RRtype in this document apply. [RFC6394] also |
| 245 | lists many requirements, most of which this document is believed to |
| 246 | meet. Section 5 covers the applicability of this document to the use |
| 247 | cases in detail. The protocol in this document can generally be |
| 248 | referred to as the "DANE TLSA" protocol. ("TLSA" does not stand for |
| 249 | anything; it is just the name of the RRtype.) |
| 250 | |
| 251 | This document applies to both TLS [RFC5246] and Datagram TLS (DTLS) |
| 252 | [RFC6347]. In order to make the document more readable, it mostly |
| 253 | only talks about "TLS", but in all cases, it means "TLS or DTLS". |
| 254 | Although the references in this paragraph are to TLS and DTLS |
| 255 | version 1.2, the DANE TLSA protocol can also be used with earlier |
| 256 | versions of TLS and DTLS. |
| 257 | |
| 258 | This document only relates to securely associating certificates for |
| 259 | TLS and DTLS with host names; retrieving certificates from DNS for |
| 260 | other protocols is handled in other documents. For example, keys for |
| 261 | IPsec are covered in [RFC4025], and keys for Secure SHell (SSH) are |
| 262 | covered in [RFC4255]. |
| 263 | |
| 264 | 1.3. Method for Securing Certificate Associations |
| 265 | |
| 266 | A certificate association is formed from a piece of information |
| 267 | identifying a certificate and the domain name where the server |
| 268 | application runs. The combination of a trust anchor and a domain |
| 269 | name can also be a certificate association. |
| 270 | |
| 271 | A DNS query can return multiple certificate associations, such as in |
| 272 | the case of a server that is changing from one certificate to another |
| 273 | (described in more detail in Appendix A.4). |
| 274 | |
| 275 | This document only applies to PKIX [RFC5280] certificates, not |
| 276 | certificates of other formats. |
| 277 | |
| 278 | |
| 279 | |
| 280 | |
| 281 | |
| 282 | Hoffman & Schlyter Standards Track [Page 5] |
| 283 | \f |
| 284 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 285 | |
| 286 | |
| 287 | This document defines a secure method to associate the certificate |
| 288 | that is obtained from the TLS server with a domain name using DNS; |
| 289 | the DNS information needs to be protected by DNSSEC. Because the |
| 290 | certificate association was retrieved based on a DNS query, the |
| 291 | domain name in the query is by definition associated with the |
| 292 | certificate. Note that this document does not cover how to associate |
| 293 | certificates with domain names for application protocols that depend |
| 294 | on SRV, NAPTR, and similar DNS resource records. It is expected that |
| 295 | future documents will cover methods for making those associations, |
| 296 | and those documents may or may not need to update this one. |
| 297 | |
| 298 | DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035], uses |
| 299 | cryptographic keys and digital signatures to provide authentication |
| 300 | of DNS data. Information that is retrieved from the DNS and that is |
| 301 | validated using DNSSEC is thereby proved to be the authoritative |
| 302 | data. The DNSSEC signature needs to be validated on all responses |
| 303 | that use DNSSEC in order to assure the proof of origin of the data. |
| 304 | |
| 305 | This document does not specify how DNSSEC validation occurs because |
| 306 | there are many different proposals for how a client might get |
| 307 | validated DNSSEC results, such as from a DNSSEC-aware resolver that |
| 308 | is coded in the application, from a trusted DNSSEC resolver on the |
| 309 | machine on which the application is running, or from a trusted DNSSEC |
| 310 | resolver with which the application is communicating over an |
| 311 | authenticated and integrity-protected channel or network. This is |
| 312 | described in more detail in Section 7 of [RFC4033]. |
| 313 | |
| 314 | This document only relates to getting the DNS information for the |
| 315 | certificate association securely using DNSSEC; other secure DNS |
| 316 | mechanisms are out of scope. |
| 317 | |
| 318 | 1.4. Terminology |
| 319 | |
| 320 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| 321 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| 322 | document are to be interpreted as described in RFC 2119 [RFC2119]. |
| 323 | |
| 324 | This document also makes use of standard PKIX, DNSSEC, TLS, and DNS |
| 325 | terminology. See [RFC5280], [RFC4033], [RFC5246], and STD 13 |
| 326 | [RFC1034] [RFC1035], respectively, for these terms. In addition, |
| 327 | terms related to TLS-protected application services and DNS names are |
| 328 | taken from [RFC6125]. |
| 329 | |
| 330 | |
| 331 | |
| 332 | |
| 333 | |
| 334 | |
| 335 | |
| 336 | |
| 337 | |
| 338 | Hoffman & Schlyter Standards Track [Page 6] |
| 339 | \f |
| 340 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 341 | |
| 342 | |
| 343 | 2. The TLSA Resource Record |
| 344 | |
| 345 | The TLSA DNS resource record (RR) is used to associate a TLS server |
| 346 | certificate or public key with the domain name where the record is |
| 347 | found, thus forming a "TLSA certificate association". The semantics |
| 348 | of how the TLSA RR is interpreted are given later in this document. |
| 349 | |
| 350 | The type value for the TLSA RR type is defined in Section 7.1. |
| 351 | |
| 352 | The TLSA RR is class independent. |
| 353 | |
| 354 | The TLSA RR has no special Time to Live (TTL) requirements. |
| 355 | |
| 356 | 2.1. TLSA RDATA Wire Format |
| 357 | |
| 358 | The RDATA for a TLSA RR consists of a one-octet certificate usage |
| 359 | field, a one-octet selector field, a one-octet matching type field, |
| 360 | and the certificate association data field. |
| 361 | |
| 362 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 |
| 363 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 |
| 364 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 365 | | Cert. Usage | Selector | Matching Type | / |
| 366 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |
| 367 | / / |
| 368 | / Certificate Association Data / |
| 369 | / / |
| 370 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 371 | |
| 372 | 2.1.1. The Certificate Usage Field |
| 373 | |
| 374 | A one-octet value, called "certificate usage", specifies the provided |
| 375 | association that will be used to match the certificate presented in |
| 376 | the TLS handshake. This value is defined in a new IANA registry (see |
| 377 | Section 7.2) in order to make it easier to add additional certificate |
| 378 | usages in the future. The certificate usages defined in this |
| 379 | document are: |
| 380 | |
| 381 | 0 -- Certificate usage 0 is used to specify a CA certificate, or |
| 382 | the public key of such a certificate, that MUST be found in any of |
| 383 | the PKIX certification paths for the end entity certificate given |
| 384 | by the server in TLS. This certificate usage is sometimes |
| 385 | referred to as "CA constraint" because it limits which CA can be |
| 386 | used to issue certificates for a given service on a host. The |
| 387 | presented certificate MUST pass PKIX certification path |
| 388 | validation, and a CA certificate that matches the TLSA record MUST |
| 389 | be included as part of a valid certification path. Because this |
| 390 | certificate usage allows both trust anchors and CA certificates, |
| 391 | |
| 392 | |
| 393 | |
| 394 | Hoffman & Schlyter Standards Track [Page 7] |
| 395 | \f |
| 396 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 397 | |
| 398 | |
| 399 | the certificate might or might not have the basicConstraints |
| 400 | extension present. |
| 401 | |
| 402 | 1 -- Certificate usage 1 is used to specify an end entity |
| 403 | certificate, or the public key of such a certificate, that MUST be |
| 404 | matched with the end entity certificate given by the server in |
| 405 | TLS. This certificate usage is sometimes referred to as "service |
| 406 | certificate constraint" because it limits which end entity |
| 407 | certificate can be used by a given service on a host. The target |
| 408 | certificate MUST pass PKIX certification path validation and MUST |
| 409 | match the TLSA record. |
| 410 | |
| 411 | 2 -- Certificate usage 2 is used to specify a certificate, or the |
| 412 | public key of such a certificate, that MUST be used as the trust |
| 413 | anchor when validating the end entity certificate given by the |
| 414 | server in TLS. This certificate usage is sometimes referred to as |
| 415 | "trust anchor assertion" and allows a domain name administrator to |
| 416 | specify a new trust anchor -- for example, if the domain issues |
| 417 | its own certificates under its own CA that is not expected to be |
| 418 | in the end users' collection of trust anchors. The target |
| 419 | certificate MUST pass PKIX certification path validation, with any |
| 420 | certificate matching the TLSA record considered to be a trust |
| 421 | anchor for this certification path validation. |
| 422 | |
| 423 | 3 -- Certificate usage 3 is used to specify a certificate, or the |
| 424 | public key of such a certificate, that MUST match the end entity |
| 425 | certificate given by the server in TLS. This certificate usage is |
| 426 | sometimes referred to as "domain-issued certificate" because it |
| 427 | allows for a domain name administrator to issue certificates for a |
| 428 | domain without involving a third-party CA. The target certificate |
| 429 | MUST match the TLSA record. The difference between certificate |
| 430 | usage 1 and certificate usage 3 is that certificate usage 1 |
| 431 | requires that the certificate pass PKIX validation, but PKIX |
| 432 | validation is not tested for certificate usage 3. |
| 433 | |
| 434 | The certificate usages defined in this document explicitly only apply |
| 435 | to PKIX-formatted certificates in DER encoding [X.690]. If TLS |
| 436 | allows other formats later, or if extensions to this RRtype are made |
| 437 | that accept other formats for certificates, those certificates will |
| 438 | need their own certificate usage values. |
| 439 | |
| 440 | 2.1.2. The Selector Field |
| 441 | |
| 442 | A one-octet value, called "selector", specifies which part of the TLS |
| 443 | certificate presented by the server will be matched against the |
| 444 | association data. This value is defined in a new IANA registry (see |
| 445 | Section 7.3). The selectors defined in this document are: |
| 446 | |
| 447 | |
| 448 | |
| 449 | |
| 450 | Hoffman & Schlyter Standards Track [Page 8] |
| 451 | \f |
| 452 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 453 | |
| 454 | |
| 455 | 0 -- Full certificate: the Certificate binary structure as defined |
| 456 | in [RFC5280] |
| 457 | |
| 458 | 1 -- SubjectPublicKeyInfo: DER-encoded binary structure as defined |
| 459 | in [RFC5280] |
| 460 | |
| 461 | (Note that the use of "selector" in this document is completely |
| 462 | unrelated to the use of "selector" in DomainKeys Identified Mail |
| 463 | (DKIM) [RFC6376].) |
| 464 | |
| 465 | 2.1.3. The Matching Type Field |
| 466 | |
| 467 | A one-octet value, called "matching type", specifies how the |
| 468 | certificate association is presented. This value is defined in a new |
| 469 | IANA registry (see Section 7.4). The types defined in this document |
| 470 | are: |
| 471 | |
| 472 | 0 -- Exact match on selected content |
| 473 | |
| 474 | 1 -- SHA-256 hash of selected content [RFC6234] |
| 475 | |
| 476 | 2 -- SHA-512 hash of selected content [RFC6234] |
| 477 | |
| 478 | If the TLSA record's matching type is a hash, having the record use |
| 479 | the same hash algorithm that was used in the signature in the |
| 480 | certificate (if possible) will assist clients that support a small |
| 481 | number of hash algorithms. |
| 482 | |
| 483 | 2.1.4. The Certificate Association Data Field |
| 484 | |
| 485 | This field specifies the "certificate association data" to be |
| 486 | matched. These bytes are either raw data (that is, the full |
| 487 | certificate or its SubjectPublicKeyInfo, depending on the selector) |
| 488 | for matching type 0, or the hash of the raw data for matching types 1 |
| 489 | and 2. The data refers to the certificate in the association, not to |
| 490 | the TLS ASN.1 Certificate object. |
| 491 | |
| 492 | 2.2. TLSA RR Presentation Format |
| 493 | |
| 494 | The presentation format of the RDATA portion (as defined in |
| 495 | [RFC1035]) is as follows: |
| 496 | |
| 497 | o The certificate usage field MUST be represented as an 8-bit |
| 498 | unsigned integer. |
| 499 | |
| 500 | o The selector field MUST be represented as an 8-bit unsigned |
| 501 | integer. |
| 502 | |
| 503 | |
| 504 | |
| 505 | |
| 506 | Hoffman & Schlyter Standards Track [Page 9] |
| 507 | \f |
| 508 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 509 | |
| 510 | |
| 511 | o The matching type field MUST be represented as an 8-bit unsigned |
| 512 | integer. |
| 513 | |
| 514 | o The certificate association data field MUST be represented as a |
| 515 | string of hexadecimal characters. Whitespace is allowed within |
| 516 | the string of hexadecimal characters, as described in [RFC1035]. |
| 517 | |
| 518 | 2.3. TLSA RR Examples |
| 519 | |
| 520 | In the following examples, the domain name is formed using the rules |
| 521 | in Section 3. |
| 522 | |
| 523 | An example of a hashed (SHA-256) association of a PKIX CA |
| 524 | certificate: |
| 525 | |
| 526 | _443._tcp.www.example.com. IN TLSA ( |
| 527 | 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9 |
| 528 | 7983a1d16e8a410e4561cb106618e971 ) |
| 529 | |
| 530 | An example of a hashed (SHA-512) subject public key association of a |
| 531 | PKIX end entity certificate: |
| 532 | |
| 533 | _443._tcp.www.example.com. IN TLSA ( |
| 534 | 1 1 2 92003ba34942dc74152e2f2c408d29ec |
| 535 | a5a520e7f2e06bb944f4dca346baf63c |
| 536 | 1b177615d466f6c4b71c216a50292bd5 |
| 537 | 8c9ebdd2f74e38fe51ffd48c43326cbc ) |
| 538 | |
| 539 | An example of a full certificate association of a PKIX end entity |
| 540 | certificate: |
| 541 | |
| 542 | _443._tcp.www.example.com. IN TLSA ( |
| 543 | 3 0 0 30820307308201efa003020102020... ) |
| 544 | |
| 545 | 3. Domain Names for TLSA Certificate Associations |
| 546 | |
| 547 | Unless there is a protocol-specific specification that is different |
| 548 | than this one, TLSA resource records are stored at a prefixed DNS |
| 549 | domain name. The prefix is prepared in the following manner: |
| 550 | |
| 551 | 1. The decimal representation of the port number on which a TLS- |
| 552 | based service is assumed to exist is prepended with an underscore |
| 553 | character ("_") to become the left-most label in the prepared |
| 554 | domain name. This number has no leading zeros. |
| 555 | |
| 556 | |
| 557 | |
| 558 | |
| 559 | |
| 560 | |
| 561 | |
| 562 | Hoffman & Schlyter Standards Track [Page 10] |
| 563 | \f |
| 564 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 565 | |
| 566 | |
| 567 | 2. The protocol name of the transport on which a TLS-based service |
| 568 | is assumed to exist is prepended with an underscore character |
| 569 | ("_") to become the second left-most label in the prepared domain |
| 570 | name. The transport names defined for this protocol are "tcp", |
| 571 | "udp", and "sctp". |
| 572 | |
| 573 | 3. The base domain name is appended to the result of step 2 to |
| 574 | complete the prepared domain name. The base domain name is the |
| 575 | fully qualified DNS domain name [RFC1035] of the TLS server, with |
| 576 | the additional restriction that every label MUST meet the rules |
| 577 | of [RFC0952]. The latter restriction means that, if the query is |
| 578 | for an internationalized domain name, it MUST use the A-label |
| 579 | form as defined in [RFC5890]. |
| 580 | |
| 581 | For example, to request a TLSA resource record for an HTTP server |
| 582 | running TLS on port 443 at "www.example.com", |
| 583 | "_443._tcp.www.example.com" is used in the request. To request a |
| 584 | TLSA resource record for an SMTP server running the STARTTLS protocol |
| 585 | on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is |
| 586 | used. |
| 587 | |
| 588 | 4. Use of TLSA Records in TLS |
| 589 | |
| 590 | Section 2.1 of this document defines the mandatory matching rules for |
| 591 | the data from the TLSA certificate associations and the certificates |
| 592 | received from the TLS server. |
| 593 | |
| 594 | The TLS session that is to be set up MUST be for the specific port |
| 595 | number and transport name that was given in the TLSA query. |
| 596 | |
| 597 | Some specifications for applications that run over TLS, such as |
| 598 | [RFC2818] for HTTP, require that the server's certificate have a |
| 599 | domain name that matches the host name expected by the client. Some |
| 600 | specifications, such as [RFC6125], detail how to match the identity |
| 601 | given in a PKIX certificate with those expected by the user. |
| 602 | |
| 603 | If a TLSA record has certificate usage 2, the corresponding TLS |
| 604 | server SHOULD send the certificate that is referenced just like it |
| 605 | currently sends intermediate certificates. |
| 606 | |
| 607 | 4.1. Usable Certificate Associations |
| 608 | |
| 609 | An implementation of this protocol makes a DNS query for TLSA |
| 610 | records, validates these records using DNSSEC, and uses the resulting |
| 611 | TLSA records and validation status to modify its responses to the TLS |
| 612 | server. |
| 613 | |
| 614 | |
| 615 | |
| 616 | |
| 617 | |
| 618 | Hoffman & Schlyter Standards Track [Page 11] |
| 619 | \f |
| 620 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 621 | |
| 622 | |
| 623 | Determining whether a TLSA RRSet can be used MUST be based on the |
| 624 | DNSSEC validation state (as defined in [RFC4033]). |
| 625 | |
| 626 | o A TLSA RRSet whose DNSSEC validation state is secure MUST be used |
| 627 | as a certificate association for TLS unless a local policy would |
| 628 | prohibit the use of the specific certificate association in the |
| 629 | secure TLSA RRSet. |
| 630 | |
| 631 | o If the DNSSEC validation state on the response to the request for |
| 632 | the TLSA RRSet is bogus, this MUST cause TLS not to be started or, |
| 633 | if the TLS negotiation is already in progress, MUST cause the |
| 634 | connection to be aborted. |
| 635 | |
| 636 | o A TLSA RRSet whose DNSSEC validation state is indeterminate or |
| 637 | insecure cannot be used for TLS and MUST be considered unusable. |
| 638 | |
| 639 | Clients that validate the DNSSEC signatures themselves MUST use |
| 640 | standard DNSSEC validation procedures. Clients that rely on another |
| 641 | entity to perform the DNSSEC signature validation MUST use a secure |
| 642 | mechanism between themselves and the validator. Examples of secure |
| 643 | transports to other hosts include TSIG [RFC2845], SIG(0) [RFC2931], |
| 644 | and IPsec [RFC6071]. Note that it is not sufficient to use secure |
| 645 | transport to a DNS resolver that does not do DNSSEC signature |
| 646 | validation. See Section 8.3 for more security considerations related |
| 647 | to external validators. |
| 648 | |
| 649 | If a certificate association contains a certificate usage, selector, |
| 650 | or matching type that is not understood by the TLS client, that |
| 651 | certificate association MUST be considered unusable. If the |
| 652 | comparison data for a certificate is malformed, the certificate |
| 653 | association MUST be considered unusable. |
| 654 | |
| 655 | If a certificate association contains a matching type or certificate |
| 656 | association data that uses a cryptographic algorithm that is |
| 657 | considered too weak for the TLS client's policy, the certificate |
| 658 | association MUST be considered unusable. |
| 659 | |
| 660 | If an application receives zero usable certificate associations from |
| 661 | a DNS request or from its cache, it processes TLS in the normal |
| 662 | fashion without any input from the TLSA records. If an application |
| 663 | receives one or more usable certificate associations, it attempts to |
| 664 | match each certificate association with the TLS server's end entity |
| 665 | certificate until a successful match is found. During the TLS |
| 666 | handshake, if none of the certificate associations matches the |
| 667 | certificate given by the TLS server, the TLS client MUST abort the |
| 668 | handshake. |
| 669 | |
| 670 | |
| 671 | |
| 672 | |
| 673 | |
| 674 | Hoffman & Schlyter Standards Track [Page 12] |
| 675 | \f |
| 676 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 677 | |
| 678 | |
| 679 | An attacker who is able to divert a user to a server under his |
| 680 | control is also likely to be able to block DNS requests from the user |
| 681 | or DNS responses being sent to the user. Thus, in order to achieve |
| 682 | any security benefit from certificate usage 0 or 1, an application |
| 683 | that sends a request for TLSA records needs to get either a valid |
| 684 | signed response containing TLSA records or verification that the |
| 685 | domain is insecure or indeterminate. If a request for a TLSA record |
| 686 | does not meet one of those two criteria but the application continues |
| 687 | with the TLS handshake anyway, the application has gotten no benefit |
| 688 | from TLSA and SHOULD NOT make any internal or external indication |
| 689 | that TLSA was applied. If an application has a configuration setting |
| 690 | that has turned on TLSA use, or has any indication that TLSA is in |
| 691 | use (regardless of whether or not this is configurable), that |
| 692 | application either MUST NOT start a TLS connection or it MUST abort a |
| 693 | TLS handshake if both of the two criteria above are not met. |
| 694 | |
| 695 | The application can perform the TLSA lookup before initiating the TLS |
| 696 | handshake, or do it during the TLS handshake: the choice is up to the |
| 697 | client. |
| 698 | |
| 699 | 5. TLSA and DANE Use Cases and Requirements |
| 700 | |
| 701 | The different types of certificate associations defined in TLSA are |
| 702 | matched with various sections of [RFC6394]. The use cases from |
| 703 | Section 3 of [RFC6394] are covered in this document as follows: |
| 704 | |
| 705 | 3.1 CA Constraints -- Implemented using certificate usage 0. |
| 706 | |
| 707 | 3.2 Certificate Constraints -- Implemented using certificate usage 1. |
| 708 | |
| 709 | 3.3 Trust Anchor Assertion and Domain-Issued Certificates -- |
| 710 | Implemented using certificate usages 2 and 3, respectively. |
| 711 | |
| 712 | The requirements from Section 4 of [RFC6394] are covered in this |
| 713 | document as follows: |
| 714 | |
| 715 | Multiple Ports -- The TLSA records for different application services |
| 716 | running on a single host can be distinguished through the service |
| 717 | name and port number prefixed to the host name (see Section 3). |
| 718 | |
| 719 | No Downgrade -- Section 4 specifies the conditions under which a |
| 720 | client can process and act upon TLSA records. Specifically, if |
| 721 | the DNSSEC status for the TLSA resource record set is determined |
| 722 | to be bogus, the TLS connection (if started) will fail. |
| 723 | |
| 724 | Encapsulation -- Encapsulation is covered in the TLSA response |
| 725 | semantics. |
| 726 | |
| 727 | |
| 728 | |
| 729 | |
| 730 | Hoffman & Schlyter Standards Track [Page 13] |
| 731 | \f |
| 732 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 733 | |
| 734 | |
| 735 | Predictability -- The appendices of this specification provide |
| 736 | operational considerations and implementation guidance in order to |
| 737 | enable application developers to form a consistent interpretation |
| 738 | of the recommended client behavior. |
| 739 | |
| 740 | Opportunistic Security -- If a client conformant to this |
| 741 | specification can reliably determine the presence of a TLSA |
| 742 | record, it will attempt to use this information. Conversely, if a |
| 743 | client can reliably determine the absence of any TLSA record, it |
| 744 | will fall back to processing TLS in the normal fashion. This is |
| 745 | discussed in Section 4. |
| 746 | |
| 747 | Combination -- Multiple TLSA records can be published for a given |
| 748 | host name, thus enabling the client to construct multiple TLSA |
| 749 | certificate associations that reflect different assertions. No |
| 750 | support is provided to combine two TLSA certificate associations |
| 751 | in a single operation. |
| 752 | |
| 753 | Roll-over -- TLSA records are processed in the normal manner within |
| 754 | the scope of the DNS protocol, including the TTL expiration of the |
| 755 | records. This ensures that clients will not latch onto assertions |
| 756 | made by expired TLSA records, and will be able to transition from |
| 757 | using one public key or certificate usage to another. |
| 758 | |
| 759 | Simple Key Management -- The SubjectPublicKeyInfo selector in the |
| 760 | TLSA record provides a mode that enables a domain holder to only |
| 761 | have to maintain a single long-lived public/private key pair |
| 762 | without the need to manage certificates. Appendix A outlines the |
| 763 | usefulness and the potential downsides to using this mode. |
| 764 | |
| 765 | Minimal Dependencies -- This specification relies on DNSSEC to |
| 766 | protect the origin authenticity and integrity of the TLSA resource |
| 767 | record set. Additionally, if DNSSEC validation is not performed |
| 768 | on the system that wishes to use TLSA certificate bindings, this |
| 769 | specification requires that the "last mile" be over a secure |
| 770 | transport. There are no other deployment dependencies for this |
| 771 | approach. |
| 772 | |
| 773 | Minimal Options -- The operating modes map precisely to the DANE use |
| 774 | cases and requirements. DNSSEC use is mandatory in that this |
| 775 | specification encourages applications to use only those TLSA |
| 776 | records that are shown to be validated. |
| 777 | |
| 778 | Wildcards -- Wildcards are covered in a limited manner in the TLSA |
| 779 | request syntax; see Appendix A. |
| 780 | |
| 781 | Redirection -- Redirection is covered in the TLSA request syntax; see |
| 782 | Appendix A. |
| 783 | |
| 784 | |
| 785 | |
| 786 | Hoffman & Schlyter Standards Track [Page 14] |
| 787 | \f |
| 788 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 789 | |
| 790 | |
| 791 | 6. Mandatory-to-Implement Features |
| 792 | |
| 793 | TLS clients conforming to this specification MUST be able to |
| 794 | correctly interpret TLSA records with certificate usages 0, 1, 2, |
| 795 | and 3. TLS clients conforming to this specification MUST be able to |
| 796 | compare a certificate association with a certificate from the TLS |
| 797 | handshake using selector types 0 and 1, and matching type 0 (no hash |
| 798 | used) and matching type 1 (SHA-256), and SHOULD be able to make such |
| 799 | comparisons with matching type 2 (SHA-512). |
| 800 | |
| 801 | 7. IANA Considerations |
| 802 | |
| 803 | IANA has made the assignments in this section. |
| 804 | |
| 805 | In the following sections, "RFC Required" was chosen for TLSA |
| 806 | certificate usages and "Specification Required" for selectors and |
| 807 | matching types because of the amount of detail that is likely to be |
| 808 | needed for implementers to correctly implement new certificate usages |
| 809 | as compared to new selectors and matching types. |
| 810 | |
| 811 | 7.1. TLSA RRtype |
| 812 | |
| 813 | This document uses a new DNS RR type, TLSA, whose value (52) was |
| 814 | allocated by IANA from the Resource Record (RR) TYPEs subregistry of |
| 815 | the Domain Name System (DNS) Parameters registry. |
| 816 | |
| 817 | 7.2. TLSA Certificate Usages |
| 818 | |
| 819 | This document creates a new registry, "TLSA Certificate Usages". The |
| 820 | registry policy is "RFC Required". The initial entries in the |
| 821 | registry are: |
| 822 | |
| 823 | Value Short description Reference |
| 824 | ---------------------------------------------------------- |
| 825 | 0 CA constraint RFC 6698 |
| 826 | 1 Service certificate constraint RFC 6698 |
| 827 | 2 Trust anchor assertion RFC 6698 |
| 828 | 3 Domain-issued certificate RFC 6698 |
| 829 | 4-254 Unassigned |
| 830 | 255 Private use |
| 831 | |
| 832 | Applications to the registry can request specific values that have |
| 833 | yet to be assigned. |
| 834 | |
| 835 | |
| 836 | |
| 837 | |
| 838 | |
| 839 | |
| 840 | |
| 841 | |
| 842 | Hoffman & Schlyter Standards Track [Page 15] |
| 843 | \f |
| 844 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 845 | |
| 846 | |
| 847 | 7.3. TLSA Selectors |
| 848 | |
| 849 | This document creates a new registry, "TLSA Selectors". The registry |
| 850 | policy is "Specification Required". The initial entries in the |
| 851 | registry are: |
| 852 | |
| 853 | Value Short description Reference |
| 854 | ---------------------------------------------------------- |
| 855 | 0 Full certificate RFC 6698 |
| 856 | 1 SubjectPublicKeyInfo RFC 6698 |
| 857 | 2-254 Unassigned |
| 858 | 255 Private use |
| 859 | |
| 860 | Applications to the registry can request specific values that have |
| 861 | yet to be assigned. |
| 862 | |
| 863 | 7.4. TLSA Matching Types |
| 864 | |
| 865 | This document creates a new registry, "TLSA Matching Types". The |
| 866 | registry policy is "Specification Required". The initial entries in |
| 867 | the registry are: |
| 868 | |
| 869 | Value Short description Reference |
| 870 | ---------------------------------------------------------- |
| 871 | 0 No hash used RFC 6698 |
| 872 | 1 SHA-256 RFC 6234 |
| 873 | 2 SHA-512 RFC 6234 |
| 874 | 3-254 Unassigned |
| 875 | 255 Private use |
| 876 | |
| 877 | Applications to the registry can request specific values that have |
| 878 | yet to be assigned. |
| 879 | |
| 880 | 8. Security Considerations |
| 881 | |
| 882 | The security of the DNS RRtype described in this document relies on |
| 883 | the security of DNSSEC to verify that the TLSA record has not been |
| 884 | altered. |
| 885 | |
| 886 | A rogue DNS administrator who changes the A, AAAA, and/or TLSA |
| 887 | records for a domain name can cause the client to go to an |
| 888 | unauthorized server that will appear authorized, unless the client |
| 889 | performs PKIX certification path validation and rejects the |
| 890 | certificate. That administrator could probably get a certificate |
| 891 | issued by some CA anyway, so this is not an additional threat. |
| 892 | |
| 893 | |
| 894 | |
| 895 | |
| 896 | |
| 897 | |
| 898 | Hoffman & Schlyter Standards Track [Page 16] |
| 899 | \f |
| 900 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 901 | |
| 902 | |
| 903 | If the authentication mechanism for adding or changing TLSA data in a |
| 904 | zone is weaker than the authentication mechanism for changing the A |
| 905 | and/or AAAA records, a man-in-the-middle who can redirect traffic to |
| 906 | his site may be able to impersonate the attacked host in TLS if he |
| 907 | can use the weaker authentication mechanism. A better design for |
| 908 | authenticating DNS would be to have the same level of authentication |
| 909 | used for all DNS additions and changes for a particular domain name. |
| 910 | |
| 911 | Secure Socket Layer (SSL) proxies can sometimes act as a man-in-the- |
| 912 | middle for TLS clients. In these scenarios, the clients add a new |
| 913 | trust anchor whose private key is kept on the SSL proxy; the proxy |
| 914 | intercepts TLS requests, creates a new TLS session with the intended |
| 915 | host, and sets up a TLS session with the client using a certificate |
| 916 | that chains to the trust anchor installed in the client by the proxy. |
| 917 | In such environments, using TLSA records will prevent the SSL proxy |
| 918 | from functioning as expected because the TLS client will get a |
| 919 | certificate association from the DNS that will not match the |
| 920 | certificate that the SSL proxy uses with the client. The client, |
| 921 | seeing the proxy's new certificate for the supposed destination, will |
| 922 | not set up a TLS session. |
| 923 | |
| 924 | Client treatment of any information included in the trust anchor is a |
| 925 | matter of local policy. This specification does not mandate that |
| 926 | such information be inspected or validated by the server's domain |
| 927 | name administrator. |
| 928 | |
| 929 | If a server's certificate is revoked, or if an intermediate CA in a |
| 930 | chain between the server and a trust anchor has its certificate |
| 931 | revoked, a TLSA record with a certificate usage of 2 that matches the |
| 932 | revoked certificate would in essence override the revocation because |
| 933 | the client would treat that revoked certificate as a trust anchor and |
| 934 | thus not check its revocation status. Because of this, domain |
| 935 | administrators need to be responsible for being sure that the keys or |
| 936 | certificates used in TLSA records with a certificate usage of 2 are |
| 937 | in fact able to be used as reliable trust anchors. |
| 938 | |
| 939 | Certificates that are delivered in TLSA with certificate usage 2 |
| 940 | fundamentally change the way the TLS server's end entity certificate |
| 941 | is evaluated. For example, the server's certificate might chain to |
| 942 | an existing CA through an intermediate CA that has certain policy |
| 943 | restrictions, and the certificate would not pass those restrictions |
| 944 | and thus normally be rejected. That intermediate CA could issue |
| 945 | itself a new certificate without the policy restrictions and tell its |
| 946 | customers to use that certificate with certificate usage 2. This in |
| 947 | essence allows an intermediate CA to become a trust anchor for |
| 948 | certificates that the end user might have expected to chain to an |
| 949 | existing trust anchor. |
| 950 | |
| 951 | |
| 952 | |
| 953 | |
| 954 | Hoffman & Schlyter Standards Track [Page 17] |
| 955 | \f |
| 956 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 957 | |
| 958 | |
| 959 | If an administrator wishes to stop using a TLSA record, the |
| 960 | administrator can simply remove it from the DNS. Normal clients will |
| 961 | stop using the TLSA record after the TTL has expired. Replay attacks |
| 962 | against the TLSA record are not possible after the expiration date on |
| 963 | the RRsig of the TLSA record that was removed. |
| 964 | |
| 965 | Generators of TLSA records should be aware that the client's full |
| 966 | trust of a certificate association retrieved from a TLSA record may |
| 967 | be a matter of local policy. While such trust is limited to the |
| 968 | specific domain name, protocol, and port for which the TLSA query was |
| 969 | made, local policy may decline to accept the certificate (for reasons |
| 970 | such as weak cryptography), as is also the case with PKIX trust |
| 971 | anchors. |
| 972 | |
| 973 | 8.1. Comparing DANE to Public CAs |
| 974 | |
| 975 | As stated above, the security of the DNS RRtype described in this |
| 976 | document relies on the security of DNSSEC to verify that the TLSA |
| 977 | record has not been altered. This section describes where the |
| 978 | security of public CAs and the security of TLSA are similar and |
| 979 | different. This section applies equally to other security-related |
| 980 | DNS RRtypes such as keys for IPsec and SSH. |
| 981 | |
| 982 | DNSSEC forms certificates (the binding of an identity to a key) by |
| 983 | combining a DNSKEY, DS, or DLV resource record with an associated |
| 984 | RRSIG record. These records then form a signing chain extending from |
| 985 | the client's trust anchors to the RR of interest. |
| 986 | |
| 987 | Although the DNSSEC protocol does not enforce it, DNSKEYs are often |
| 988 | marked with a SEP flag indicating whether the key is a Zone Signing |
| 989 | Key (ZSK) or a Key Signing Key (KSK). ZSKs protect records in the |
| 990 | zone (including DS and DLV records), and KSKs protect ZSK DNSKEY |
| 991 | records. This allows KSKs to be stored offline. |
| 992 | |
| 993 | The TLSA RRtype allows keys from the DNSSEC PKI hierarchy to |
| 994 | authenticate keys wrapped in PKIX certificates for a particular host |
| 995 | name, protocol, and port. |
| 996 | |
| 997 | With the exception of the DLV RRtype, all of these certificates |
| 998 | constrain the keys they identify to names that are within the zone |
| 999 | signing the certificate. In order for a domain's DLV resource |
| 1000 | records to be honored, the domain must be configured as a DLV domain, |
| 1001 | and the domain's DNSKEYs must be configured as trust anchors or be |
| 1002 | authentic [RFC5074]. |
| 1003 | |
| 1004 | |
| 1005 | |
| 1006 | |
| 1007 | |
| 1008 | |
| 1009 | |
| 1010 | Hoffman & Schlyter Standards Track [Page 18] |
| 1011 | \f |
| 1012 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1013 | |
| 1014 | |
| 1015 | 8.1.1. Risk of Key Compromise |
| 1016 | |
| 1017 | The risk that a given certificate that has a valid signing chain is |
| 1018 | fake is related to the number of keys that can contribute to the |
| 1019 | validation of the certificate, the quality of protection each private |
| 1020 | key receives, the value of each key to an attacker, and the value of |
| 1021 | falsifying the certificate. |
| 1022 | |
| 1023 | DNSSEC allows any set of domains to be configured as trust anchors |
| 1024 | and/or DLVs, but most clients are likely to use the root zone as |
| 1025 | their only trust anchor. Also, because a given DNSKEY can only sign |
| 1026 | resource records for that zone, the number of private keys capable of |
| 1027 | compromising a given TLSA resource record is limited to the number of |
| 1028 | zones between the TLSA resource record and the nearest trust anchor, |
| 1029 | plus any configured DLV domains. Typically, this will be six keys, |
| 1030 | half of which will be KSKs. |
| 1031 | |
| 1032 | PKIX only describes how to validate a certificate based on a client- |
| 1033 | chosen set of trust anchors, but says nothing about how many trust |
| 1034 | anchors to use or how they should be constrained. As currently |
| 1035 | deployed, most PKIX clients use a large number of trust anchors |
| 1036 | provided with the client or operating system software. These trust |
| 1037 | anchors are selected carefully, but with a desire for broad |
| 1038 | interoperability. The trust anchors and CA certificates for public |
| 1039 | CAs rarely have name constraints applied. |
| 1040 | |
| 1041 | A combination of technical protections, process controls, and |
| 1042 | personnel experience contribute to the quality of security that keys |
| 1043 | receive. |
| 1044 | |
| 1045 | o The security surrounding DNSSEC DNSKEYs varies significantly. The |
| 1046 | KSK/ZSK split allows the KSK to be stored offline and protected |
| 1047 | more carefully than the ZSK, but not all domains do so. The |
| 1048 | security applied to a zone's DNSKEYs should be proportional to the |
| 1049 | value of the domain, but that is difficult to estimate. For |
| 1050 | example, the root DNSKEY has protections and controls comparable |
| 1051 | to or exceeding those of public CAs. On the other end of the |
| 1052 | spectrum, small domains might provide no more protection to their |
| 1053 | keys than they do to their other data. |
| 1054 | |
| 1055 | o The security surrounding public CAs also varies. However, due to |
| 1056 | financial incentives and standards imposed by clients for |
| 1057 | acceptance into their trust anchor stores, CAs generally employ |
| 1058 | security experts and protect their keys carefully, though highly |
| 1059 | public compromises have occurred. |
| 1060 | |
| 1061 | |
| 1062 | |
| 1063 | |
| 1064 | |
| 1065 | |
| 1066 | Hoffman & Schlyter Standards Track [Page 19] |
| 1067 | \f |
| 1068 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1069 | |
| 1070 | |
| 1071 | 8.1.2. Impact of Key Compromise |
| 1072 | |
| 1073 | The impact of a key compromise differs significantly between the two |
| 1074 | models. |
| 1075 | |
| 1076 | o DNSKEYs are inherently limited in what they can sign, so a |
| 1077 | compromise of the DNSKEY for "example.com" provides no avenue of |
| 1078 | attack against "example.org". Even the impact of a compromise of |
| 1079 | .com's DNSKEY, while considerable, would be limited to .com |
| 1080 | domains. Only the compromise of the root DNSKEY would have the |
| 1081 | equivalent impact of an unconstrained public CA. |
| 1082 | |
| 1083 | o Public CAs are not typically constrained in what names they can |
| 1084 | sign, and therefore a compromise of even one CA allows the |
| 1085 | attacker to generate a certificate for any name in the DNS. A |
| 1086 | domain holder can get a certificate from any willing CA, or even |
| 1087 | multiple CAs simultaneously, making it impossible for a client to |
| 1088 | determine whether the certificate it is validating is legitimate |
| 1089 | or fraudulent. |
| 1090 | |
| 1091 | Because a TLSA certificate association is constrained to its |
| 1092 | associated name, protocol, and port, the PKIX certificate is |
| 1093 | similarly constrained, even if its public CAs signing the certificate |
| 1094 | (if any) are not. |
| 1095 | |
| 1096 | 8.1.3. Detection of Key Compromise |
| 1097 | |
| 1098 | If a key is compromised, rapid and reliable detection is important in |
| 1099 | order to limit the impact of the compromise. In this regard, neither |
| 1100 | model prevents an attacker from near-invisibly attacking their |
| 1101 | victim, provided that the necessary keys are compromised. |
| 1102 | |
| 1103 | If a public CA is compromised, only the victim will see the |
| 1104 | fraudulent certificate, as there is typically no publicly accessible |
| 1105 | directory of all the certificates issued by a CA that can be |
| 1106 | inspected. DNS resource records are typically published publicly. |
| 1107 | However, the attacker could also allow the uncompromised records to |
| 1108 | be published to the Internet as usual but provide a compromised DNS |
| 1109 | view to the victim to achieve the same effect. |
| 1110 | |
| 1111 | 8.1.4. Spoofing Hostnames |
| 1112 | |
| 1113 | Some CAs implement technical controls to ensure that certificates are |
| 1114 | not issued to domains with names similar to domains that are popular |
| 1115 | and prone to attack. Of course, an attacker can attempt to |
| 1116 | circumvent this restriction by finding a CA willing to issue the |
| 1117 | certificate anyway. However, by using DNSSEC and TLSA, the attacker |
| 1118 | can circumvent this check completely. |
| 1119 | |
| 1120 | |
| 1121 | |
| 1122 | Hoffman & Schlyter Standards Track [Page 20] |
| 1123 | \f |
| 1124 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1125 | |
| 1126 | |
| 1127 | 8.2. DNS Caching |
| 1128 | |
| 1129 | Implementations of this protocol rely heavily on the DNS, and are |
| 1130 | thus prone to security attacks based on the deliberate |
| 1131 | mis-association of TLSA records and DNS names. Implementations need |
| 1132 | to be cautious in assuming the continuing validity of an association |
| 1133 | between a TLSA record and a DNS name. |
| 1134 | |
| 1135 | In particular, implementations SHOULD rely on their DNS resolver for |
| 1136 | confirmation of an association between a TLSA record and a DNS name, |
| 1137 | rather than caching the result of previous domain name lookups. Many |
| 1138 | platforms already can cache domain name lookups locally when |
| 1139 | appropriate, and they SHOULD be configured to do so. It is proper |
| 1140 | for these lookups to be cached, however, only when the TTL (Time To |
| 1141 | Live) information reported by the DNS makes it likely that the cached |
| 1142 | information will remain useful. |
| 1143 | |
| 1144 | If implementations cache the results of domain name lookups in order |
| 1145 | to achieve a performance improvement, they MUST observe the TTL |
| 1146 | information reported by DNS. Implementations that fail to follow |
| 1147 | this rule could be spoofed or have access denied when a previously |
| 1148 | accessed server's TLSA record changes, such as during a certificate |
| 1149 | rollover. |
| 1150 | |
| 1151 | 8.3. External DNSSEC Validators |
| 1152 | |
| 1153 | Due to a lack of DNSSEC support in the most commonly deployed stub |
| 1154 | resolvers today, some ISPs have begun checking DNSSEC in the |
| 1155 | recursive resolvers they provide to their customers, setting the |
| 1156 | Authentic Data (AD) flag as appropriate. DNSSEC-aware clients could |
| 1157 | use that data, ignoring the fact that the DNSSEC data has been |
| 1158 | validated externally. Because there is typically no authentication |
| 1159 | of the recursive resolver or integrity protection of the data and AD |
| 1160 | flag between the client and the recursive resolver, this can be |
| 1161 | trivially spoofed by an attacker. |
| 1162 | |
| 1163 | However, even with secure communications between a host and the |
| 1164 | external validating resolver, there is a risk that the external |
| 1165 | validator could become compromised. Nothing prevents a compromised |
| 1166 | external DNSSEC validator from claiming that all the records it |
| 1167 | provides are secure, even if the data is falsified, unless the client |
| 1168 | checks the DNSSEC data itself (rendering the external validator |
| 1169 | unnecessary). |
| 1170 | |
| 1171 | For this reason, DNSSEC validation is best performed on-host, even |
| 1172 | when a secure path to an external validator is available. |
| 1173 | |
| 1174 | |
| 1175 | |
| 1176 | |
| 1177 | |
| 1178 | Hoffman & Schlyter Standards Track [Page 21] |
| 1179 | \f |
| 1180 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1181 | |
| 1182 | |
| 1183 | 9. Acknowledgements |
| 1184 | |
| 1185 | Many of the ideas in this document have been discussed over many |
| 1186 | years. More recently, the ideas have been discussed by the authors |
| 1187 | and others in a more focused fashion. In particular, some of the |
| 1188 | ideas and words here originated with Paul Vixie, Dan Kaminsky, Jeff |
| 1189 | Hodges, Phillip Hallam-Baker, Simon Josefsson, Warren Kumari, Adam |
| 1190 | Langley, Ben Laurie, Ilari Liusvaara, Ondrej Mikle, Scott Schmit, |
| 1191 | Ondrej Sury, Richard Barnes, Jim Schaad, Stephen Farrell, Suresh |
| 1192 | Krishnaswamy, Peter Palfrader, Pieter Lexis, Wouter Wijngaards, John |
| 1193 | Gilmore, and Murray Kucherawy. |
| 1194 | |
| 1195 | This document has also been greatly helped by many active |
| 1196 | participants of the DANE Working Group. |
| 1197 | |
| 1198 | 10. References |
| 1199 | |
| 1200 | 10.1. Normative References |
| 1201 | |
| 1202 | [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", |
| 1203 | STD 13, RFC 1034, November 1987. |
| 1204 | |
| 1205 | [RFC1035] Mockapetris, P., "Domain names - implementation and |
| 1206 | specification", STD 13, RFC 1035, November 1987. |
| 1207 | |
| 1208 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| 1209 | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| 1210 | |
| 1211 | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
| 1212 | Rose, "DNS Security Introduction and Requirements", |
| 1213 | RFC 4033, March 2005. |
| 1214 | |
| 1215 | [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
| 1216 | Rose, "Resource Records for the DNS Security Extensions", |
| 1217 | RFC 4034, March 2005. |
| 1218 | |
| 1219 | [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
| 1220 | Rose, "Protocol Modifications for the DNS Security |
| 1221 | Extensions", RFC 4035, March 2005. |
| 1222 | |
| 1223 | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security |
| 1224 | (TLS) Protocol Version 1.2", RFC 5246, August 2008. |
| 1225 | |
| 1226 | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., |
| 1227 | Housley, R., and W. Polk, "Internet X.509 Public Key |
| 1228 | Infrastructure Certificate and Certificate Revocation List |
| 1229 | (CRL) Profile", RFC 5280, May 2008. |
| 1230 | |
| 1231 | |
| 1232 | |
| 1233 | |
| 1234 | Hoffman & Schlyter Standards Track [Page 22] |
| 1235 | \f |
| 1236 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1237 | |
| 1238 | |
| 1239 | [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and |
| 1240 | Verification of Domain-Based Application Service Identity |
| 1241 | within Internet Public Key Infrastructure Using X.509 |
| 1242 | (PKIX) Certificates in the Context of Transport Layer |
| 1243 | Security (TLS)", RFC 6125, March 2011. |
| 1244 | |
| 1245 | [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer |
| 1246 | Security Version 1.2", RFC 6347, January 2012. |
| 1247 | |
| 1248 | 10.2. Informative References |
| 1249 | |
| 1250 | [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet |
| 1251 | host table specification", RFC 952, October 1985. |
| 1252 | |
| 1253 | [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for |
| 1254 | specifying the location of services (DNS SRV)", RFC 2782, |
| 1255 | February 2000. |
| 1256 | |
| 1257 | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. |
| 1258 | |
| 1259 | [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. |
| 1260 | Wellington, "Secret Key Transaction Authentication for DNS |
| 1261 | (TSIG)", RFC 2845, May 2000. |
| 1262 | |
| 1263 | [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures |
| 1264 | ( SIG(0)s)", RFC 2931, September 2000. |
| 1265 | |
| 1266 | [RFC4025] Richardson, M., "A Method for Storing IPsec Keying |
| 1267 | Material in DNS", RFC 4025, March 2005. |
| 1268 | |
| 1269 | [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely |
| 1270 | Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, |
| 1271 | January 2006. |
| 1272 | |
| 1273 | [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", |
| 1274 | RFC 4641, September 2006. |
| 1275 | |
| 1276 | [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, |
| 1277 | November 2007. |
| 1278 | |
| 1279 | [RFC5890] Klensin, J., "Internationalized Domain Names for |
| 1280 | Applications (IDNA): Definitions and Document Framework", |
| 1281 | RFC 5890, August 2010. |
| 1282 | |
| 1283 | [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) |
| 1284 | Extensions: Extension Definitions", RFC 6066, |
| 1285 | January 2011. |
| 1286 | |
| 1287 | |
| 1288 | |
| 1289 | |
| 1290 | Hoffman & Schlyter Standards Track [Page 23] |
| 1291 | \f |
| 1292 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1293 | |
| 1294 | |
| 1295 | [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and |
| 1296 | Internet Key Exchange (IKE) Document Roadmap", RFC 6071, |
| 1297 | February 2011. |
| 1298 | |
| 1299 | [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms |
| 1300 | (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. |
| 1301 | |
| 1302 | [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., |
| 1303 | "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, |
| 1304 | September 2011. |
| 1305 | |
| 1306 | [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based |
| 1307 | Authentication of Named Entities (DANE)", RFC 6394, |
| 1308 | October 2011. |
| 1309 | |
| 1310 | [X.690] "Recommendation ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, |
| 1311 | Information technology - ASN.1 encoding rules: |
| 1312 | Specification of Basic Encoding Rules (BER), Canonical |
| 1313 | Encoding Rules (CER) and Distinguished Encoding Rules |
| 1314 | (DER)", July 2002. |
| 1315 | |
| 1316 | |
| 1317 | |
| 1318 | |
| 1319 | |
| 1320 | |
| 1321 | |
| 1322 | |
| 1323 | |
| 1324 | |
| 1325 | |
| 1326 | |
| 1327 | |
| 1328 | |
| 1329 | |
| 1330 | |
| 1331 | |
| 1332 | |
| 1333 | |
| 1334 | |
| 1335 | |
| 1336 | |
| 1337 | |
| 1338 | |
| 1339 | |
| 1340 | |
| 1341 | |
| 1342 | |
| 1343 | |
| 1344 | |
| 1345 | |
| 1346 | Hoffman & Schlyter Standards Track [Page 24] |
| 1347 | \f |
| 1348 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1349 | |
| 1350 | |
| 1351 | Appendix A. Operational Considerations for Deploying TLSA Records |
| 1352 | |
| 1353 | A.1. Creating TLSA Records |
| 1354 | |
| 1355 | When creating TLSA records, care must be taken to avoid |
| 1356 | misconfigurations. Section 4 of this document states that a TLSA |
| 1357 | RRSet whose validation state is secure MUST be used. This means that |
| 1358 | the existence of such a RRSet effectively disables other forms of |
| 1359 | name and path validation. A misconfigured TLSA RRSet will |
| 1360 | effectively disable access to the TLS server for all conforming |
| 1361 | clients, and this document does not provide any means of making a |
| 1362 | gradual transition to using TLSA. |
| 1363 | |
| 1364 | When creating TLSA records with certificate usage 0 (CA certificate) |
| 1365 | or usage 2 (trust anchor), one needs to understand the implications |
| 1366 | when choosing between selector type 0 (Full certificate) and 1 |
| 1367 | (SubjectPublicKeyInfo). A careful choice is required because |
| 1368 | different methods for building trust chains are used by different TLS |
| 1369 | clients. The following outlines the cases that one ought to be aware |
| 1370 | of and discusses the implications of the choice of selector type. |
| 1371 | |
| 1372 | Certificate usage 2 is not affected by the different types of chain |
| 1373 | building when the end entity certificate is the same as the trust |
| 1374 | anchor certificate. |
| 1375 | |
| 1376 | A.1.1. Ambiguities and Corner Cases When TLS Clients Build Trust Chains |
| 1377 | |
| 1378 | TLS clients can implement their own chain-building code rather than |
| 1379 | rely on the chain presented by the TLS server. This means that, |
| 1380 | except for the end entity certificate, any certificate presented in |
| 1381 | the suggested chain might or might not be present in the final chain |
| 1382 | built by the client. |
| 1383 | |
| 1384 | Certificates that the client can use to replace certificates from the |
| 1385 | original chain include: |
| 1386 | |
| 1387 | o Client's trust anchors |
| 1388 | |
| 1389 | o Certificates cached locally |
| 1390 | |
| 1391 | o Certificates retrieved from a URI listed in an Authority |
| 1392 | Information Access X.509v3 extension |
| 1393 | |
| 1394 | CAs frequently reissue certificates with different validity periods, |
| 1395 | signature algorithms (such as a different hash algorithm in the |
| 1396 | signature algorithm), CA key pairs (such as for a cross-certificate), |
| 1397 | |
| 1398 | |
| 1399 | |
| 1400 | |
| 1401 | |
| 1402 | Hoffman & Schlyter Standards Track [Page 25] |
| 1403 | \f |
| 1404 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1405 | |
| 1406 | |
| 1407 | or PKIX extensions where the public key and subject remain the same. |
| 1408 | These reissued certificates are the certificates that the TLS client |
| 1409 | can use in place of an original certificate. |
| 1410 | |
| 1411 | Clients are known to exchange or remove certificates that could cause |
| 1412 | TLSA certificate associations that rely on the full certificate to |
| 1413 | fail. For example: |
| 1414 | |
| 1415 | o The client considers the signature algorithm of a certificate to |
| 1416 | no longer be sufficiently secure. |
| 1417 | |
| 1418 | o The client might not have an associated root certificate in its |
| 1419 | trust store and instead uses a cross-certificate with an identical |
| 1420 | subject and public key. |
| 1421 | |
| 1422 | A.1.2. Choosing a Selector Type |
| 1423 | |
| 1424 | In this section, "false-negative failure" means that a client will |
| 1425 | not accept the TLSA certificate association for a certificate |
| 1426 | designated by the DNS administrator. Also, "false-positive |
| 1427 | acceptance" means that the client accepts a TLSA association for a |
| 1428 | certificate that is not designated by the DNS administrator. |
| 1429 | |
| 1430 | A.1.2.1. Selector Type 0 (Full Certificate) |
| 1431 | |
| 1432 | The "Full certificate" selector provides the most precise |
| 1433 | specification of a TLSA certificate association, capturing all |
| 1434 | fields of the PKIX certificate. For a DNS administrator, the best |
| 1435 | course to avoid false-negative failures in the client when using this |
| 1436 | selector is: |
| 1437 | |
| 1438 | 1. If a CA issued a replacement certificate, don't associate to CA |
| 1439 | certificates that have a signature algorithm with a hash that is |
| 1440 | considered weak by local policy. |
| 1441 | |
| 1442 | 2. Determine how common client applications process the TLSA |
| 1443 | certificate association using a fresh client installation -- that |
| 1444 | is, with the local certificate cache empty. |
| 1445 | |
| 1446 | |
| 1447 | |
| 1448 | |
| 1449 | |
| 1450 | |
| 1451 | |
| 1452 | |
| 1453 | |
| 1454 | |
| 1455 | |
| 1456 | |
| 1457 | |
| 1458 | Hoffman & Schlyter Standards Track [Page 26] |
| 1459 | \f |
| 1460 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1461 | |
| 1462 | |
| 1463 | A.1.2.2. Selector Type 1 (SubjectPublicKeyInfo) |
| 1464 | |
| 1465 | A SubjectPublicKeyInfo selector gives greater flexibility in avoiding |
| 1466 | some false-negative failures caused by trust-chain-building |
| 1467 | algorithms used in clients. |
| 1468 | |
| 1469 | One specific use case ought to be noted: creating a TLSA certificate |
| 1470 | association to CA certificate I1 that directly signed end entity |
| 1471 | certificate S1 of the server. The case can be illustrated by the |
| 1472 | following graph: |
| 1473 | |
| 1474 | +----+ +----+ |
| 1475 | | I1 | | I2 | |
| 1476 | +----+ +----+ |
| 1477 | | | |
| 1478 | v v |
| 1479 | +----+ +----+ |
| 1480 | | S1 | | S1 | |
| 1481 | +----+ +----+ |
| 1482 | Certificate chain sent by A different validation path |
| 1483 | server in TLS handshake built by the TLS client |
| 1484 | |
| 1485 | I2 is a reissued version of CA certificate I1 (that is, it has a |
| 1486 | different hash in its signature algorithm). |
| 1487 | |
| 1488 | In the above scenario, both certificates I1 and I2 that sign S1 need |
| 1489 | to have identical SubjectPublicKeyInfo fields because the key used to |
| 1490 | sign S1 is fixed. An association to SubjectPublicKeyInfo (selector |
| 1491 | type 1) will always succeed in such a case, but an association with a |
| 1492 | full certificate (selector type 0) might not work due to a false- |
| 1493 | negative failure. |
| 1494 | |
| 1495 | The attack surface is a bit broader compared to the "Full |
| 1496 | certificate" selector: the DNS administrator might unintentionally |
| 1497 | specify an association that would lead to false-positive acceptance. |
| 1498 | |
| 1499 | o The administrator must know or trust that the CA does not engage |
| 1500 | in bad practices, such as not sharing the key of I1 for unrelated |
| 1501 | CA certificates (which would lead to trust-chain redirection). If |
| 1502 | possible, the administrator ought to review all CA certificates |
| 1503 | that have the same SubjectPublicKeyInfo field. |
| 1504 | |
| 1505 | o The administrator ought to understand whether some PKIX extension |
| 1506 | may adversely affect security of the association. If possible, |
| 1507 | administrators ought to review all CA certificates that share the |
| 1508 | SubjectPublicKeyInfo. |
| 1509 | |
| 1510 | |
| 1511 | |
| 1512 | |
| 1513 | |
| 1514 | Hoffman & Schlyter Standards Track [Page 27] |
| 1515 | \f |
| 1516 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1517 | |
| 1518 | |
| 1519 | o The administrator ought to understand that any CA could, in the |
| 1520 | future, issue a certificate that contains the same |
| 1521 | SubjectPublicKeyInfo. Therefore, new chains can crop up in the |
| 1522 | future without any warning. |
| 1523 | |
| 1524 | Using the SubjectPublicKeyInfo selector for association with a |
| 1525 | certificate in a chain above I1 needs to be decided on a case-by-case |
| 1526 | basis: there are too many possibilities based on the issuing CA's |
| 1527 | practices. Unless the full implications of such an association are |
| 1528 | understood by the administrator, using selector type 0 is a better |
| 1529 | option from a security perspective. |
| 1530 | |
| 1531 | A.2. Provisioning TLSA Records in DNS |
| 1532 | |
| 1533 | A.2.1. Provisioning TLSA Records with Aliases |
| 1534 | |
| 1535 | The TLSA resource record is not special in the DNS; it acts exactly |
| 1536 | like any other RRtype where the queried name has one or more labels |
| 1537 | prefixed to the base name, such as the SRV RRtype [RFC2782]. This |
| 1538 | affects the way that the TLSA resource record is used when aliasing |
| 1539 | in the DNS. |
| 1540 | |
| 1541 | Note that the IETF sometimes adds new types of aliasing in the DNS. |
| 1542 | If that happens in the future, those aliases might affect TLSA |
| 1543 | records, hopefully in a good way. |
| 1544 | |
| 1545 | A.2.1.1. Provisioning TLSA Records with CNAME Records |
| 1546 | |
| 1547 | Using CNAME to alias in DNS only aliases from the exact name given, |
| 1548 | not any zones below the given name. For example, assume that a zone |
| 1549 | file has only the following: |
| 1550 | |
| 1551 | sub1.example.com. IN CNAME sub2.example.com. |
| 1552 | |
| 1553 | In this case, a request for the A record at "bottom.sub1.example.com" |
| 1554 | would not return any records because the CNAME given only aliases the |
| 1555 | name given. Assume, instead, the zone file has the following: |
| 1556 | |
| 1557 | sub3.example.com. IN CNAME sub4.example.com. |
| 1558 | bottom.sub3.example.com. IN CNAME bottom.sub4.example.com. |
| 1559 | |
| 1560 | In this case, a request for the A record at bottom.sub3.example.com |
| 1561 | would in fact return whatever value for the A record exists at |
| 1562 | bottom.sub4.example.com. |
| 1563 | |
| 1564 | |
| 1565 | |
| 1566 | |
| 1567 | |
| 1568 | |
| 1569 | |
| 1570 | Hoffman & Schlyter Standards Track [Page 28] |
| 1571 | \f |
| 1572 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1573 | |
| 1574 | |
| 1575 | Application implementations and full-service resolvers request DNS |
| 1576 | records using libraries that automatically follow CNAME (and DNAME) |
| 1577 | aliasing. This allows hosts to put TLSA records in their own zones |
| 1578 | or to use CNAME to do redirection. |
| 1579 | |
| 1580 | If the owner of the original domain wants a TLSA record for the same, |
| 1581 | they simply enter it under the defined prefix: |
| 1582 | |
| 1583 | ; No TLSA record in target domain |
| 1584 | ; |
| 1585 | sub5.example.com. IN CNAME sub6.example.com. |
| 1586 | _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab... |
| 1587 | sub6.example.com. IN A 192.0.2.1 |
| 1588 | sub6.example.com. IN AAAA 2001:db8::1 |
| 1589 | |
| 1590 | If the owner of the original domain wants to have the target domain |
| 1591 | host the TLSA record, the original domain uses a CNAME record: |
| 1592 | |
| 1593 | ; TLSA record for original domain has CNAME to target domain |
| 1594 | ; |
| 1595 | sub5.example.com. IN CNAME sub6.example.com. |
| 1596 | _443._tcp.sub5.example.com. IN CNAME _443._tcp.sub6.example.com. |
| 1597 | sub6.example.com. IN A 192.0.2.1 |
| 1598 | sub6.example.com. IN AAAA 2001:db8::1 |
| 1599 | _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4... |
| 1600 | |
| 1601 | Note that it is acceptable for both the original domain and the |
| 1602 | target domain to have TLSA records, but the two records are |
| 1603 | unrelated. Consider the following: |
| 1604 | |
| 1605 | ; TLSA record in both the original and target domain |
| 1606 | ; |
| 1607 | sub5.example.com. IN CNAME sub6.example.com. |
| 1608 | _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab... |
| 1609 | sub6.example.com. IN A 192.0.2.1 |
| 1610 | sub6.example.com. IN AAAA 2001:db8::1 |
| 1611 | _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49... |
| 1612 | |
| 1613 | In this example, someone looking for the TLSA record for |
| 1614 | sub5.example.com would always get the record whose value starts with |
| 1615 | "308202c5308201ab"; the TLSA record whose value starts with |
| 1616 | "ac49d9ba4570ac49" would only be sought by someone who is looking for |
| 1617 | the TLSA record for sub6.example.com, and never for sub5.example.com. |
| 1618 | Note that deploying different certificates for multiple services |
| 1619 | located at a shared TLS listener often requires the use of TLS SNI |
| 1620 | (Server Name Indication) [RFC6066]. |
| 1621 | |
| 1622 | |
| 1623 | |
| 1624 | |
| 1625 | |
| 1626 | Hoffman & Schlyter Standards Track [Page 29] |
| 1627 | \f |
| 1628 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1629 | |
| 1630 | |
| 1631 | Note that these methods use the normal method for DNS aliasing using |
| 1632 | CNAME: the DNS client requests the record type that they actually |
| 1633 | want. |
| 1634 | |
| 1635 | A.2.1.2. Provisioning TLSA Records with DNAME Records |
| 1636 | |
| 1637 | Using DNAME records allows a zone owner to alias an entire subtree of |
| 1638 | names below the name that has the DNAME. This allows the wholesale |
| 1639 | aliasing of prefixed records such as those used by TLSA, SRV, and so |
| 1640 | on without aliasing the name itself. However, because DNAME can only |
| 1641 | be used for subtrees of a base name, it is rarely used to alias |
| 1642 | individual hosts that might also be running TLS. |
| 1643 | |
| 1644 | ; TLSA record in target domain, visible in original domain via DNAME |
| 1645 | ; |
| 1646 | sub5.example.com. IN CNAME sub6.example.com. |
| 1647 | _tcp.sub5.example.com. IN DNAME _tcp.sub6.example.com. |
| 1648 | sub6.example.com. IN A 192.0.2.1 |
| 1649 | sub6.example.com. IN AAAA 2001:db8::1 |
| 1650 | _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4... |
| 1651 | |
| 1652 | A.2.1.3. Provisioning TLSA Records with Wildcards |
| 1653 | |
| 1654 | Wildcards are generally not terribly useful for RRtypes that require |
| 1655 | prefixing because one can only wildcard at a layer below the host |
| 1656 | name. For example, if one wants to have the same TLSA record for |
| 1657 | every TCP port for www.example.com, the result might be: |
| 1658 | |
| 1659 | *._tcp.www.example.com. IN TLSA 1 1 1 5c1502a6549c423b... |
| 1660 | |
| 1661 | This is possibly useful in some scenarios where the same service is |
| 1662 | offered on many ports or the same certificate and/or key is used for |
| 1663 | all services on a host. Note that the domain being searched for is |
| 1664 | not necessarily related to the domain name found in the certificate, |
| 1665 | so a certificate with a wildcard in it is not searched for using a |
| 1666 | wildcard in the search request. |
| 1667 | |
| 1668 | A.3. Securing the Last Hop |
| 1669 | |
| 1670 | As described in Section 4, an application processing TLSA records |
| 1671 | must know the DNSSEC validity of those records. There are many ways |
| 1672 | for the application to determine this securely, and this |
| 1673 | specification does not mandate any single method. |
| 1674 | |
| 1675 | |
| 1676 | |
| 1677 | |
| 1678 | |
| 1679 | |
| 1680 | |
| 1681 | |
| 1682 | Hoffman & Schlyter Standards Track [Page 30] |
| 1683 | \f |
| 1684 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1685 | |
| 1686 | |
| 1687 | Some common methods for an application to know the DNSSEC validity of |
| 1688 | TLSA records include: |
| 1689 | |
| 1690 | o The application can have its own DNS resolver and DNSSEC |
| 1691 | validation stack. |
| 1692 | |
| 1693 | o The application can communicate through a trusted channel (such as |
| 1694 | requests to the operating system under which the application is |
| 1695 | running) to a local DNS resolver that does DNSSEC validation. |
| 1696 | |
| 1697 | o The application can communicate through a secured channel (such as |
| 1698 | requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local |
| 1699 | DNS resolver that does DNSSEC validation. |
| 1700 | |
| 1701 | o The application can communicate through a secured channel (such as |
| 1702 | requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local |
| 1703 | DNS resolver that does not do DNSSEC validation, but gets |
| 1704 | responses through a secured channel from a different DNS resolver |
| 1705 | that does DNSSEC validation. |
| 1706 | |
| 1707 | A.4. Handling Certificate Rollover |
| 1708 | |
| 1709 | Certificate rollover is handled in much the same way as for rolling |
| 1710 | DNSSEC zone signing keys using the pre-publish key rollover method |
| 1711 | [RFC4641]. Suppose example.com has a single TLSA record for a TLS |
| 1712 | service on TCP port 990: |
| 1713 | |
| 1714 | _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015... |
| 1715 | |
| 1716 | To start the rollover process, obtain or generate the new certificate |
| 1717 | or SubjectPublicKeyInfo to be used after the rollover and generate |
| 1718 | the new TLSA record. Add that record alongside the old one: |
| 1719 | |
| 1720 | _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015... |
| 1721 | _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30... |
| 1722 | |
| 1723 | After the new records have propagated to the authoritative |
| 1724 | nameservers and the TTL of the old record has expired, switch to the |
| 1725 | new certificate on the TLS server. Once this has occurred, the old |
| 1726 | TLSA record can be removed: |
| 1727 | |
| 1728 | _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30... |
| 1729 | |
| 1730 | This completes the certificate rollover. |
| 1731 | |
| 1732 | |
| 1733 | |
| 1734 | |
| 1735 | |
| 1736 | |
| 1737 | |
| 1738 | Hoffman & Schlyter Standards Track [Page 31] |
| 1739 | \f |
| 1740 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1741 | |
| 1742 | |
| 1743 | Appendix B. Pseudocode for Using TLSA |
| 1744 | |
| 1745 | This appendix describes, in pseudocode format, the interactions given |
| 1746 | earlier in this specification. If the steps below disagree with the |
| 1747 | text earlier in the document, the steps earlier in the document ought |
| 1748 | to be considered correct and this text incorrect. |
| 1749 | |
| 1750 | Note that this pseudocode is more strict than the normative text. |
| 1751 | For instance, it forces an order on the evaluation of criteria, which |
| 1752 | is not mandatory from the normative text. |
| 1753 | |
| 1754 | B.1. Helper Functions |
| 1755 | |
| 1756 | // implement the function for exiting |
| 1757 | function Finish (F) = { |
| 1758 | if (F == ABORT_TLS) { |
| 1759 | abort the TLS handshake or prevent TLS from starting |
| 1760 | exit |
| 1761 | } |
| 1762 | |
| 1763 | if (F == NO_TLSA) { |
| 1764 | fall back to non-TLSA certificate validation |
| 1765 | exit |
| 1766 | } |
| 1767 | |
| 1768 | if (F == ACCEPT) { |
| 1769 | accept the TLS connection |
| 1770 | exit |
| 1771 | } |
| 1772 | |
| 1773 | // unreachable |
| 1774 | } |
| 1775 | |
| 1776 | // implement the selector function |
| 1777 | function Select (S, X) = { |
| 1778 | // Full certificate |
| 1779 | if (S == 0) { |
| 1780 | return X in DER encoding |
| 1781 | } |
| 1782 | |
| 1783 | // SubjectPublicKeyInfo |
| 1784 | if (S == 1) { |
| 1785 | return X.SubjectPublicKeyInfo in DER encoding |
| 1786 | } |
| 1787 | |
| 1788 | // unreachable |
| 1789 | } |
| 1790 | |
| 1791 | |
| 1792 | |
| 1793 | |
| 1794 | Hoffman & Schlyter Standards Track [Page 32] |
| 1795 | \f |
| 1796 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1797 | |
| 1798 | |
| 1799 | // implement the matching function |
| 1800 | function Match (M, X, Y) { |
| 1801 | // Exact match on selected content |
| 1802 | if (M == 0) { |
| 1803 | return (X == Y) |
| 1804 | } |
| 1805 | |
| 1806 | // SHA-256 hash of selected content |
| 1807 | if (M == 1) { |
| 1808 | return (SHA-256(X) == Y) |
| 1809 | } |
| 1810 | |
| 1811 | // SHA-512 hash of selected content |
| 1812 | if (M == 2) { |
| 1813 | return (SHA-512(X) == Y) |
| 1814 | } |
| 1815 | |
| 1816 | // unreachable |
| 1817 | } |
| 1818 | |
| 1819 | B.2. Main TLSA Pseudocode |
| 1820 | |
| 1821 | TLS connect using [transport] to [name] on [port] and receiving end |
| 1822 | entity cert C for the TLS server: |
| 1823 | |
| 1824 | (TLSArecords, ValState) = DNSSECValidatedLookup( |
| 1825 | domainname=_[port]._[transport].[name], RRtype=TLSA) |
| 1826 | |
| 1827 | // check for states that would change processing |
| 1828 | if (ValState == BOGUS) { |
| 1829 | Finish(ABORT_TLS) |
| 1830 | } |
| 1831 | if ((ValState == INDETERMINATE) or (ValState == INSECURE)) { |
| 1832 | Finish(NO_TLSA) |
| 1833 | } |
| 1834 | // if here, ValState must be SECURE |
| 1835 | |
| 1836 | for each R in TLSArecords { |
| 1837 | // unusable records include unknown certUsage, unknown |
| 1838 | // selectorType, unknown matchingType, erroneous RDATA, and |
| 1839 | // prohibited by local policy |
| 1840 | if (R is unusable) { |
| 1841 | remove R from TLSArecords |
| 1842 | } |
| 1843 | } |
| 1844 | if (length(TLSArecords) == 0) { |
| 1845 | Finish(NO_TLSA) |
| 1846 | } |
| 1847 | |
| 1848 | |
| 1849 | |
| 1850 | Hoffman & Schlyter Standards Track [Page 33] |
| 1851 | \f |
| 1852 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1853 | |
| 1854 | |
| 1855 | // A TLS client might have multiple trust anchors that it might use |
| 1856 | // when validating the TLS server's end entity (EE) certificate. |
| 1857 | // Also, there can be multiple PKIX certification paths for the |
| 1858 | // certificates given by the server in TLS. Thus, there are |
| 1859 | // possibly many chains that might need to be tested during |
| 1860 | // PKIX path validation. |
| 1861 | |
| 1862 | for each R in TLSArecords { |
| 1863 | |
| 1864 | // pass PKIX certificate validation and chain through a CA cert |
| 1865 | // that comes from TLSA |
| 1866 | if (R.certUsage == 0) { |
| 1867 | for each PKIX certification path H { |
| 1868 | if (C passes PKIX certification path validation in H) { |
| 1869 | for each D in H { |
| 1870 | if ((D is a CA certificate) and |
| 1871 | Match(R.matchingType, Select(R.selectorType, D), |
| 1872 | R.cert)) { |
| 1873 | Finish(ACCEPT) |
| 1874 | } |
| 1875 | } |
| 1876 | } |
| 1877 | } |
| 1878 | } |
| 1879 | |
| 1880 | // pass PKIX certificate validation and match EE cert from TLSA |
| 1881 | if (R.certUsage == 1) { |
| 1882 | for each PKIX certification path H { |
| 1883 | if ((C passes PKIX certificate validation in H) and |
| 1884 | Match(R.matchingType, Select(R.selectorType, C), |
| 1885 | R.cert)) { |
| 1886 | Finish(ACCEPT) |
| 1887 | } |
| 1888 | } |
| 1889 | } |
| 1890 | |
| 1891 | // pass PKIX certification validation using TLSA record as the |
| 1892 | // trust anchor |
| 1893 | if (R.certUsage == 2) { |
| 1894 | // the following assert() is merely a formalization of the |
| 1895 | // "trust anchor" condition for a certificate D matching R |
| 1896 | assert(Match(R.matchingType, Select(R.selectorType, D), R.cert)) |
| 1897 | |
| 1898 | |
| 1899 | |
| 1900 | |
| 1901 | |
| 1902 | |
| 1903 | |
| 1904 | |
| 1905 | |
| 1906 | Hoffman & Schlyter Standards Track [Page 34] |
| 1907 | \f |
| 1908 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1909 | |
| 1910 | |
| 1911 | for each PKIX certification path H that has certificate D |
| 1912 | matching R as the trust anchor { |
| 1913 | if (C passes PKIX validation in H) { |
| 1914 | Finish(ACCEPT); |
| 1915 | } |
| 1916 | } |
| 1917 | } |
| 1918 | |
| 1919 | // match the TLSA record and the TLS certificate |
| 1920 | if (R.certUsage == 3) { |
| 1921 | if Match(R.matchingType, Select(R.selectorType, C), R.cert) |
| 1922 | Finish(ACCEPT) |
| 1923 | } |
| 1924 | } |
| 1925 | |
| 1926 | } |
| 1927 | |
| 1928 | // if here, then none of the TLSA records ended in "Finish(ACCEPT)" |
| 1929 | // so abort TLS |
| 1930 | Finish(ABORT_TLS) |
| 1931 | |
| 1932 | Appendix C. Examples |
| 1933 | |
| 1934 | The following are examples of self-signed certificates that have been |
| 1935 | generated with various selectors and matching types. They were |
| 1936 | generated with one piece of software, and validated by an individual |
| 1937 | using other tools. |
| 1938 | |
| 1939 | S = Selector |
| 1940 | M = Matching Type |
| 1941 | |
| 1942 | S M Association Data |
| 1943 | 0 0 30820454308202BC020900AB58D24E77AD2AF6300D06092A86 |
| 1944 | 4886F70D0101050500306C310B3009060355040613024E4C31163014 |
| 1945 | 0603550408130D4E6F6F72642D486F6C6C616E643112301006035504 |
| 1946 | 071309416D7374657264616D310C300A060355040A13034F53333123 |
| 1947 | 30210603550403131A64616E652E6B6965762E70726163746963756D |
| 1948 | 2E6F73332E6E6C301E170D3132303131363136353730335A170D3232 |
| 1949 | 303131333136353730335A306C310B3009060355040613024E4C3116 |
| 1950 | 30140603550408130D4E6F6F72642D486F6C6C616E64311230100603 |
| 1951 | 5504071309416D7374657264616D310C300A060355040A13034F5333 |
| 1952 | 312330210603550403131A64616E652E6B6965762E70726163746963 |
| 1953 | 756D2E6F73332E6E6C308201A2300D06092A864886F70D0101010500 |
| 1954 | 0382018F003082018A0282018100E62C84A5AFE59F0A2A6B250DEE68 |
| 1955 | 7AC8C5C604F57D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B |
| 1956 | 6AD5DEA0C8771C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE |
| 1957 | 281A68230B24B9DA1A98DCBE51195B60E42FD7517C328D983E26A827 |
| 1958 | C877AB914EE4C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D5 |
| 1959 | |
| 1960 | |
| 1961 | |
| 1962 | Hoffman & Schlyter Standards Track [Page 35] |
| 1963 | \f |
| 1964 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 1965 | |
| 1966 | |
| 1967 | 8C389CC3D6D8C20662E19CF768F32441B7F7D14AEA8966CE7C32A172 |
| 1968 | 2AB38623D008029A9E4702883F8B977A1A1E5292BF8AD72239D40393 |
| 1969 | 37B86A3AC60FA001290452177BF1798609A05A130F033457A5212629 |
| 1970 | FBDDB8E70E2A9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D |
| 1971 | 4BD77DFA34035563C126AA2C3328B900E7990AC9787F01DA82F74C3D |
| 1972 | 4B6674CCECE1FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE775 |
| 1973 | 6213BD3D60831175BE290442B4AFC5AE6F46B769855A067C1097E617 |
| 1974 | 962529E166F22AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A44 |
| 1975 | 9C8D0D31BC683C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2 |
| 1976 | DDFF6B4CAC050203010001300D06092A864886F70D01010505000382 |
| 1977 | 0181002B2ABE063E9C86AC4A1F7835372091079C8276A9C2C5D1EC57 |
| 1978 | 64DE523FDDABDEAB3FD34E6FE6CBA054580A6785A663595D90132B93 |
| 1979 | D473929E81FA0887D2FFF78A81C7D014B97778AB6AC9E5E690F6F5A9 |
| 1980 | E92BB5FBAB71B857AE69B6E18BDCCB0BA6FCD9D4B084A34F3635148C |
| 1981 | 495D48FE635903B888EC1DEB2610548EDD48D63F86513A4562469831 |
| 1982 | 48C0D5DB82D73A4C350A42BB661D763430FC6C8E5F9D13EA1B76AA52 |
| 1983 | A4C358E5EA04000F794618303AB6CEEA4E9A8E9C74D73C1B0B7BAF16 |
| 1984 | DEDE7696B5E2F206F777100F5727E1684D4132F5E692F47AF6756EA8 |
| 1985 | B421000BE031B5D8F0220E436B51FB154FE9595333C13A2403F9DE08 |
| 1986 | E5DDC5A22FD6182E339593E26374450220BC14F3E40FF33F084526B0 |
| 1987 | 9C34250702E8A352B332CCCB0F9DE2CF2B338823B92AFC61C0B6B8AB |
| 1988 | DB5AF718ED8DDA97C298E46B82A01B14814868CFA4F2C36268BFFF4A |
| 1989 | 591F42658BF75918902D3E426DFE1D5FF0FC6A212071F6DA8BD833FE |
| 1990 | 2E560D87775E8EE9333C05B6FB8EB56589D910DB5EA903 |
| 1991 | |
| 1992 | 0 1 EFDDF0D915C7BDC5782C0881E1B2A95AD099FBDD06D7B1F779 |
| 1993 | 82D9364338D955 |
| 1994 | |
| 1995 | 0 2 81EE7F6C0ECC6B09B7785A9418F54432DE630DD54DC6EE9E3C |
| 1996 | 49DE547708D236D4C413C3E97E44F969E635958AA410495844127C04 |
| 1997 | 883503E5B024CF7A8F6A94 |
| 1998 | |
| 1999 | 1 0 308201A2300D06092A864886F70D01010105000382018F0030 |
| 2000 | 82018A0282018100E62C84A5AFE59F0A2A6B250DEE687AC8C5C604F5 |
| 2001 | 7D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B6AD5DEA0C877 |
| 2002 | 1C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE281A68230B24 |
| 2003 | B9DA1A98DCBE51195B60E42FD7517C328D983E26A827C877AB914EE4 |
| 2004 | C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D58C389CC3D6D8 |
| 2005 | C20662E19CF768F32441B7F7D14AEA8966CE7C32A1722AB38623D008 |
| 2006 | 029A9E4702883F8B977A1A1E5292BF8AD72239D4039337B86A3AC60F |
| 2007 | A001290452177BF1798609A05A130F033457A5212629FBDDB8E70E2A |
| 2008 | 9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D4BD77DFA3403 |
| 2009 | 5563C126AA2C3328B900E7990AC9787F01DA82F74C3D4B6674CCECE1 |
| 2010 | FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE7756213BD3D6083 |
| 2011 | 1175BE290442B4AFC5AE6F46B769855A067C1097E617962529E166F2 |
| 2012 | 2AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A449C8D0D31BC68 |
| 2013 | 3C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2DDFF6B4CAC05 |
| 2014 | 0203010001 |
| 2015 | |
| 2016 | |
| 2017 | |
| 2018 | Hoffman & Schlyter Standards Track [Page 36] |
| 2019 | \f |
| 2020 | RFC 6698 DNS-Based Authentication for TLS August 2012 |
| 2021 | |
| 2022 | |
| 2023 | 1 1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911 |
| 2024 | D9E30A924138C4 |
| 2025 | |
| 2026 | 1 2 D43165B4CDF8F8660AECCCC5344D9D9AE45FFD7E6AAB7AB9EE |
| 2027 | C169B58E11F227ED90C17330CC17B5CCEF0390066008C720CEC6AAE5 |
| 2028 | 33A934B3A2D7E232C94AB4 |
| 2029 | |
| 2030 | Authors' Addresses |
| 2031 | |
| 2032 | Paul Hoffman |
| 2033 | VPN Consortium |
| 2034 | |
| 2035 | EMail: paul.hoffman@vpnc.org |
| 2036 | |
| 2037 | |
| 2038 | Jakob Schlyter |
| 2039 | Kirei AB |
| 2040 | |
| 2041 | EMail: jakob@kirei.se |
| 2042 | |
| 2043 | |
| 2044 | |
| 2045 | |
| 2046 | |
| 2047 | |
| 2048 | |
| 2049 | |
| 2050 | |
| 2051 | |
| 2052 | |
| 2053 | |
| 2054 | |
| 2055 | |
| 2056 | |
| 2057 | |
| 2058 | |
| 2059 | |
| 2060 | |
| 2061 | |
| 2062 | |
| 2063 | |
| 2064 | |
| 2065 | |
| 2066 | |
| 2067 | |
| 2068 | |
| 2069 | |
| 2070 | |
| 2071 | |
| 2072 | |
| 2073 | |
| 2074 | Hoffman & Schlyter Standards Track [Page 37] |
| 2075 | \f |