Commit | Line | Data |
---|---|---|
5054a7f2 TL |
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 |