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