Commit | Line | Data |
---|---|---|
22e6f294 JH |
1 | |
2 | ||
3 | ||
4 | ||
5 | DANE V. Dukhovni | |
6 | Internet-Draft Two Sigma | |
7 | Intended status: Standards Track W. Hardaker | |
d8129d87 JH |
8 | Expires: February 18, 2015 Parsons |
9 | August 17, 2014 | |
22e6f294 JH |
10 | |
11 | ||
12 | SMTP security via opportunistic DANE TLS | |
d8129d87 | 13 | draft-ietf-dane-smtp-with-dane-12 |
22e6f294 JH |
14 | |
15 | Abstract | |
16 | ||
17 | This memo describes a downgrade-resistant protocol for SMTP transport | |
18 | security between Mail Transfer Agents (MTAs) based on the DNS-Based | |
19 | Authentication of Named Entities (DANE) TLSA DNS record. Adoption of | |
20 | this protocol enables an incremental transition of the Internet email | |
21 | backbone to one using encrypted and authenticated Transport Layer | |
22 | Security (TLS). | |
23 | ||
24 | Status of This Memo | |
25 | ||
26 | This Internet-Draft is submitted in full conformance with the | |
27 | provisions of BCP 78 and BCP 79. | |
28 | ||
29 | Internet-Drafts are working documents of the Internet Engineering | |
30 | Task Force (IETF). Note that other groups may also distribute | |
31 | working documents as Internet-Drafts. The list of current Internet- | |
32 | Drafts is at http://datatracker.ietf.org/drafts/current/. | |
33 | ||
34 | Internet-Drafts are draft documents valid for a maximum of six months | |
35 | and may be updated, replaced, or obsoleted by other documents at any | |
36 | time. It is inappropriate to use Internet-Drafts as reference | |
37 | material or to cite them other than as "work in progress." | |
38 | ||
d8129d87 | 39 | This Internet-Draft will expire on February 18, 2015. |
22e6f294 JH |
40 | |
41 | Copyright Notice | |
42 | ||
43 | Copyright (c) 2014 IETF Trust and the persons identified as the | |
44 | document authors. All rights reserved. | |
45 | ||
46 | This document is subject to BCP 78 and the IETF Trust's Legal | |
47 | Provisions Relating to IETF Documents | |
48 | (http://trustee.ietf.org/license-info) in effect on the date of | |
49 | publication of this document. Please review these documents | |
50 | carefully, as they describe your rights and restrictions with respect | |
51 | to this document. Code Components extracted from this document must | |
52 | include Simplified BSD License text as described in Section 4.e of | |
53 | ||
54 | ||
55 | ||
d8129d87 | 56 | Dukhovni & Hardaker Expires February 18, 2015 [Page 1] |
22e6f294 | 57 | \f |
a46255cd | 58 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
22e6f294 JH |
59 | |
60 | ||
61 | the Trust Legal Provisions and are provided without warranty as | |
62 | described in the Simplified BSD License. | |
63 | ||
64 | Table of Contents | |
65 | ||
66 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |
67 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |
68 | 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5 | |
69 | 1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 6 | |
70 | 1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 6 | |
71 | 1.3.2. Insecure server name without DNSSEC . . . . . . . . . 7 | |
a46255cd | 72 | 1.3.3. Sender policy does not scale . . . . . . . . . . . . 8 |
22e6f294 | 73 | 1.3.4. Too many certification authorities . . . . . . . . . 8 |
a46255cd JH |
74 | 2. Identifying applicable TLSA records . . . . . . . . . . . . . 9 |
75 | 2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 9 | |
76 | 2.1.1. DNS errors, bogus and indeterminate responses . . . . 9 | |
22e6f294 | 77 | 2.1.2. DNS error handling . . . . . . . . . . . . . . . . . 11 |
a46255cd JH |
78 | 2.1.3. Stub resolver considerations . . . . . . . . . . . . 12 |
79 | 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 13 | |
80 | 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 14 | |
22e6f294 JH |
81 | 2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 15 |
82 | 2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 17 | |
83 | 3. DANE authentication . . . . . . . . . . . . . . . . . . . . . 19 | |
84 | 3.1. TLSA certificate usages . . . . . . . . . . . . . . . . . 19 | |
a46255cd JH |
85 | 3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 21 |
86 | 3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 22 | |
87 | 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 23 | |
88 | 3.2. Certificate matching . . . . . . . . . . . . . . . . . . 24 | |
89 | 3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 24 | |
90 | 3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 24 | |
91 | 3.2.3. Reference identifier matching . . . . . . . . . . . . 25 | |
92 | 4. Server key management . . . . . . . . . . . . . . . . . . . . 26 | |
22e6f294 | 93 | 5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26 |
d8129d87 JH |
94 | 6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 27 |
95 | 7. Note on DANE for Message User Agents . . . . . . . . . . . . 27 | |
96 | 8. Interoperability considerations . . . . . . . . . . . . . . . 28 | |
97 | 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 28 | |
98 | 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 28 | |
99 | 9. Operational Considerations . . . . . . . . . . . . . . . . . 29 | |
100 | 9.1. Client Operational Considerations . . . . . . . . . . . . 29 | |
101 | 9.2. Publisher Operational Considerations . . . . . . . . . . 30 | |
102 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 | |
103 | 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 | |
104 | 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 | |
105 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |
106 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 | |
107 | 13.2. Informative References . . . . . . . . . . . . . . . . . 32 | |
108 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 | |
109 | ||
110 | ||
111 | ||
112 | Dukhovni & Hardaker Expires February 18, 2015 [Page 2] | |
22e6f294 | 113 | \f |
a46255cd | 114 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
22e6f294 JH |
115 | |
116 | ||
117 | 1. Introduction | |
118 | ||
119 | This memo specifies a new connection security model for Message | |
120 | Transfer Agents (MTAs). This model is motivated by key features of | |
121 | inter-domain SMTP delivery, in particular the fact that the | |
122 | destination server is selected indirectly via DNS Mail Exchange (MX) | |
123 | records and that neither email addresses nor MX hostnames signal a | |
124 | requirement for either secure or cleartext transport. Therefore, | |
125 | aside from a few manually configured exceptions, SMTP transport | |
126 | security is of necessity opportunistic. | |
127 | ||
128 | This specification uses the presence of DANE TLSA records to securely | |
129 | signal TLS support and to publish the means by which SMTP clients can | |
130 | successfully authenticate legitimate SMTP servers. This becomes | |
a46255cd JH |
131 | "opportunistic DANE TLS" and is resistant to downgrade and man-in- |
132 | the-middle (MITM) attacks. It enables an incremental transition of | |
133 | the email backbone to authenticated TLS delivery, with increased | |
134 | global protection as adoption increases. | |
22e6f294 JH |
135 | |
136 | With opportunistic DANE TLS, traffic from SMTP clients to domains | |
137 | that publish "usable" DANE TLSA records in accordance with this memo | |
138 | is authenticated and encrypted. Traffic from legacy clients or to | |
139 | domains that do not publish TLSA records will continue to be sent in | |
140 | the same manner as before, via manually configured security, (pre- | |
141 | DANE) opportunistic TLS or just cleartext SMTP. | |
142 | ||
143 | Problems with existing use of TLS in MTA to MTA SMTP that motivate | |
144 | this specification are described in Section 1.3. The specification | |
145 | itself follows in Section 2 and Section 3 which describe respectively | |
146 | how to locate and use DANE TLSA records with SMTP. In Section 6, we | |
147 | discuss application of DANE TLS to destinations for which channel | |
148 | integrity and confidentiality are mandatory. In Section 7 we briefly | |
149 | comment on potential applicability of this specification to Message | |
150 | User Agents. | |
151 | ||
152 | 1.1. Terminology | |
153 | ||
154 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
155 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |
156 | "OPTIONAL" in this document are to be interpreted as described in | |
157 | [RFC2119]. | |
158 | ||
159 | The following terms or concepts are used through the document: | |
160 | ||
161 | Man-in-the-middle or MITM attack: Active modification of network | |
162 | traffic by an adversary able to thereby compromise the | |
163 | confidentiality or integrity of the data. | |
164 | ||
165 | ||
166 | ||
167 | ||
d8129d87 | 168 | Dukhovni & Hardaker Expires February 18, 2015 [Page 3] |
22e6f294 | 169 | \f |
a46255cd | 170 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
22e6f294 JH |
171 | |
172 | ||
173 | secure, bogus, insecure, indeterminate: DNSSEC validation results, | |
174 | as defined in Section 4.3 of [RFC4035]. | |
175 | ||
176 | Validating Security-Aware Stub Resolver and Non-Validating | |
177 | Security-Aware Stub Resolver: | |
178 | Capabilities of the stub resolver in use as defined in [RFC4033]; | |
179 | note that this specification requires the use of a Security-Aware | |
a46255cd | 180 | Stub Resolver. |
22e6f294 JH |
181 | |
182 | (pre-DANE) opportunistic TLS: Best-effort use of TLS that is | |
183 | generally vulnerable to DNS forgery and STARTTLS downgrade | |
184 | attacks. When a TLS-encrypted communication channel is not | |
185 | available, message transmission takes place in the clear. MX | |
186 | record indirection generally precludes authentication even when | |
187 | TLS is available. | |
188 | ||
a46255cd JH |
189 | opportunistic DANE TLS: Best-effort use of TLS, resistant to |
190 | downgrade attacks for destinations with DNSSEC-validated TLSA | |
191 | records. When opportunistic DANE TLS is determined to be | |
192 | unavailable, clients should fall back to opportunistic TLS. | |
193 | Opportunistic DANE TLS requires support for DNSSEC, DANE and | |
194 | STARTTLS on the client side and STARTTLS plus a DNSSEC published | |
195 | TLSA record on the server side. | |
196 | ||
22e6f294 JH |
197 | reference identifier: (Special case of [RFC6125] definition). One |
198 | of the domain names associated by the SMTP client with the | |
199 | destination SMTP server for performing name checks on the server | |
200 | certificate. When name checks are applicable, at least one of the | |
201 | reference identifiers MUST match an [RFC6125] DNS-ID (or if none | |
202 | are present the [RFC6125] CN-ID) of the server certificate (see | |
203 | Section 3.2.3). | |
204 | ||
205 | MX hostname: The RRDATA of an MX record consists of a 16 bit | |
206 | preference followed by a Mail Exchange domain name (see [RFC1035], | |
207 | Section 3.3.9). We will use the term "MX hostname" to refer to | |
208 | the latter, that is, the DNS domain name found after the | |
209 | preference value in an MX record. Thus an "MX hostname" is | |
210 | specifically a reference to a DNS domain name, rather than any | |
211 | host that bears that name. | |
212 | ||
213 | delayed delivery: Email delivery is a multi-hop store & forward | |
214 | process. When an MTA is unable forward a message that may become | |
a46255cd | 215 | deliverable later the message is queued and delivery is retried |
22e6f294 JH |
216 | periodically. Some MTAs may be configured with a fallback next- |
217 | hop destination that handles messages that the MTA would otherwise | |
a46255cd JH |
218 | queue and retry. When a fallback next-hop is configured, messages |
219 | that would otherwise have to be delayed may be sent to the | |
220 | fallback next-hop destination instead. The fallback destination | |
22e6f294 JH |
221 | |
222 | ||
223 | ||
d8129d87 | 224 | Dukhovni & Hardaker Expires February 18, 2015 [Page 4] |
22e6f294 | 225 | \f |
a46255cd | 226 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
22e6f294 JH |
227 | |
228 | ||
a46255cd JH |
229 | may itself be subject to opportunistic or mandatory DANE TLS as |
230 | though it were the original message destination. | |
22e6f294 JH |
231 | |
232 | original next hop destination: The logical destination for mail | |
233 | delivery. By default this is the domain portion of the recipient | |
234 | address, but MTAs may be configured to forward mail for some or | |
235 | all recipients via designated relays. The original next hop | |
236 | destination is, respectively, either the recipient domain or the | |
237 | associated configured relay. | |
238 | ||
239 | MTA: Message Transfer Agent ([RFC5598], Section 4.3.2). | |
240 | ||
241 | MSA: Message Submission Agent ([RFC5598], Section 4.3.1). | |
242 | ||
243 | MUA: Message User Agent ([RFC5598], Section 4.2.1). | |
244 | ||
245 | RR: A DNS Resource Record | |
246 | ||
247 | RRset: A set of DNS Resource Records for a particular class, domain | |
248 | and record type. | |
249 | ||
250 | 1.2. Background | |
251 | ||
252 | The Domain Name System Security Extensions (DNSSEC) add data origin | |
253 | authentication, data integrity and data non-existence proofs to the | |
254 | Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034] | |
255 | and [RFC4035]. | |
256 | ||
257 | As described in the introduction of [RFC6698], TLS authentication via | |
258 | the existing public Certification Authority (CA) PKI suffers from an | |
259 | over-abundance of trusted parties capable of issuing certificates for | |
260 | any domain of their choice. DANE leverages the DNSSEC infrastructure | |
261 | to publish trusted public keys and certificates for use with the | |
262 | Transport Layer Security (TLS) [RFC5246] protocol via a new "TLSA" | |
263 | DNS record type. With DNSSEC each domain can only vouch for the keys | |
264 | of its directly delegated sub-domains. | |
265 | ||
266 | The TLS protocol enables secure TCP communication. In the context of | |
267 | this memo, channel security is assumed to be provided by TLS. Used | |
268 | without authentication, TLS provides only privacy protection against | |
269 | eavesdropping attacks. With authentication, TLS also provides data | |
270 | integrity protection to guard against MITM attacks. | |
271 | ||
272 | ||
273 | ||
274 | ||
275 | ||
276 | ||
277 | ||
278 | ||
279 | ||
d8129d87 | 280 | Dukhovni & Hardaker Expires February 18, 2015 [Page 5] |
22e6f294 | 281 | \f |
a46255cd | 282 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
22e6f294 JH |
283 | |
284 | ||
285 | 1.3. SMTP channel security | |
286 | ||
287 | With HTTPS, Transport Layer Security (TLS) employs X.509 certificates | |
288 | [RFC5280] issued by one of the many Certificate Authorities (CAs) | |
289 | bundled with popular web browsers to allow users to authenticate | |
290 | their "secure" websites. Before we specify a new DANE TLS security | |
291 | model for SMTP, we will explain why a new security model is needed. | |
292 | In the process, we will explain why the familiar HTTPS security model | |
293 | is inadequate to protect inter-domain SMTP traffic. | |
294 | ||
295 | The subsections below outline four key problems with applying | |
296 | traditional PKI to SMTP that are addressed by this specification. | |
297 | Since SMTP channel security policy is not explicitly specified in | |
298 | either the recipient address or the MX record, a new signaling | |
299 | mechanism is required to indicate when channel security is possible | |
300 | and should be used. The publication of TLSA records allows server | |
301 | operators to securely signal to SMTP clients that TLS is available | |
302 | and should be used. DANE TLSA makes it possible to simultaneously | |
303 | discover which destination domains support secure delivery via TLS | |
304 | and how to verify the authenticity of the associated SMTP services, | |
305 | providing a path forward to ubiquitous SMTP channel security. | |
306 | ||
307 | 1.3.1. STARTTLS downgrade attack | |
308 | ||
309 | The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop | |
a46255cd JH |
310 | protocol in a multi-hop store & forward email delivery process. An |
311 | SMTP envelope recipient address does not correspond to a specific | |
312 | transport-layer endpoint address, rather at each relay hop the | |
313 | transport-layer endpoint is the next-hop relay, while the envelope | |
314 | recipient address typically remains the same. Unlike the Hypertext | |
315 | Transfer Protocol (HTTP) and its corresponding secured version, | |
316 | HTTPS, where the use of TLS is signaled via the URI scheme, email | |
317 | recipient addresses do not directly signal transport security policy. | |
318 | Indeed, no such signaling could work well with SMTP since TLS | |
319 | encryption of SMTP protects email traffic on a hop-by-hop basis while | |
320 | email addresses could only express end-to-end policy. | |
321 | ||
322 | ||
323 | ||
324 | ||
325 | ||
326 | ||
327 | ||
328 | ||
329 | ||
330 | ||
331 | ||
332 | ||
333 | ||
334 | ||
335 | ||
d8129d87 | 336 | Dukhovni & Hardaker Expires February 18, 2015 [Page 6] |
a46255cd JH |
337 | \f |
338 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
339 | ||
22e6f294 JH |
340 | |
341 | With no mechanism available to signal transport security policy, SMTP | |
342 | relays employ a best-effort "opportunistic" security model for TLS. | |
343 | A single SMTP server TCP listening endpoint can serve both TLS and | |
344 | non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS | |
345 | command ([RFC3207]). The server signals TLS support to the client | |
346 | over a cleartext SMTP connection, and, if the client also supports | |
347 | TLS, it may negotiate a TLS encrypted channel to use for email | |
348 | transmission. The server's indication of TLS support can be easily | |
349 | suppressed by an MITM attacker. Thus pre-DANE SMTP TLS security can | |
350 | be subverted by simply downgrading a connection to cleartext. No TLS | |
351 | security feature, such as the use of PKIX, can prevent this. The | |
352 | attacker can simply disable TLS. | |
353 | ||
22e6f294 JH |
354 | 1.3.2. Insecure server name without DNSSEC |
355 | ||
356 | With SMTP, DNS Mail Exchange (MX) records abstract the next-hop | |
357 | transport endpoint and allow administrators to specify a set of | |
358 | target servers to which SMTP traffic should be directed for a given | |
359 | domain. | |
360 | ||
361 | A PKIX TLS client is vulnerable to MITM attacks unless it verifies | |
362 | that the server's certificate binds the public key to a name that | |
363 | matches one of the client's reference identifiers. A natural choice | |
364 | of reference identifier is the server's domain name. However, with | |
a46255cd JH |
365 | SMTP, server names are not directly encoded in the recipient address, |
366 | instead they are obtained indirectly via MX records. Without DNSSEC, | |
367 | the MX lookup is vulnerable to MITM and DNS cache poisoning attacks. | |
368 | Active attackers can forge DNS replies with fake MX records and can | |
369 | redirect email to servers with names of their choice. Therefore, | |
370 | secure verification of SMTP TLS certificates matching the server name | |
371 | is not possible without DNSSEC. | |
22e6f294 JH |
372 | |
373 | One might try to harden TLS for SMTP against DNS attacks by using the | |
374 | envelope recipient domain as a reference identifier and requiring | |
375 | each SMTP server to possess a trusted certificate for the envelope | |
376 | recipient domain rather than the MX hostname. Unfortunately, this is | |
377 | impractical as email for many domains is handled by third parties | |
378 | that are not in a position to obtain certificates for all the domains | |
379 | they serve. Deployment of the Server Name Indication (SNI) extension | |
380 | to TLS (see [RFC6066] Section 3) is no panacea, since SNI key | |
381 | management is operationally challenging except when the email service | |
382 | provider is also the domain's registrar and its certificate issuer; | |
383 | this is rarely the case for email. | |
384 | ||
385 | Since the recipient domain name cannot be used as the SMTP server | |
386 | reference identifier, and neither can the MX hostname without DNSSEC, | |
387 | large-scale deployment of authenticated TLS for SMTP requires that | |
388 | the DNS be secure. | |
389 | ||
a46255cd JH |
390 | |
391 | ||
d8129d87 | 392 | Dukhovni & Hardaker Expires February 18, 2015 [Page 7] |
a46255cd JH |
393 | \f |
394 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
395 | ||
396 | ||
22e6f294 JH |
397 | Since SMTP security depends critically on DNSSEC, it is important to |
398 | point out that consequently SMTP with DANE is the most conservative | |
399 | possible trust model. It trusts only what must be trusted and no | |
400 | more. Adding any other trusted actors to the mix can only reduce | |
401 | SMTP security. A sender may choose to further harden DNSSEC for | |
a46255cd | 402 | selected high-value receiving domains by configuring explicit trust |
22e6f294 | 403 | anchors for those domains instead of relying on the chain of trust |
a46255cd JH |
404 | from the root domain. However, detailed discussion of DNSSEC |
405 | security practices is out of scope for this document. | |
22e6f294 JH |
406 | |
407 | 1.3.3. Sender policy does not scale | |
408 | ||
22e6f294 JH |
409 | Sending systems are in some cases explicitly configured to use TLS |
410 | for mail sent to selected peer domains. This requires sending MTAs | |
411 | to be configured with appropriate subject names or certificate | |
412 | content digests to expect in the presented server certificates. | |
413 | Because of the heavy administrative burden, such statically | |
414 | configured SMTP secure channels are used rarely (generally only | |
415 | between domains that make bilateral arrangements with their business | |
416 | partners). Internet email, on the other hand, requires regularly | |
417 | contacting new domains for which security configurations cannot be | |
418 | established in advance. | |
419 | ||
420 | The abstraction of the SMTP transport endpoint via DNS MX records, | |
421 | often across organization boundaries, limits the use of public CA PKI | |
422 | with SMTP to a small set of sender-configured peer domains. With | |
423 | little opportunity to use TLS authentication, sending MTAs are rarely | |
424 | configured with a comprehensive list of trusted CAs. SMTP services | |
425 | that support STARTTLS often deploy X.509 certificates that are self- | |
426 | signed or issued by a private CA. | |
427 | ||
428 | 1.3.4. Too many certification authorities | |
429 | ||
430 | Even if it were generally possible to determine a secure server name, | |
431 | the SMTP client would still need to verify that the server's | |
432 | certificate chain is issued by a trusted Certification Authority (a | |
433 | trust anchor). MTAs are not interactive applications where a human | |
434 | operator can make a decision (wisely or otherwise) to selectively | |
435 | disable TLS security policy when certificate chain verification | |
a46255cd | 436 | fails. With no user to "click OK", the MTA's list of public CA trust |
22e6f294 JH |
437 | anchors would need to be comprehensive in order to avoid bouncing |
438 | mail addressed to sites that employ unknown Certification | |
439 | Authorities. | |
440 | ||
22e6f294 | 441 | |
22e6f294 | 442 | |
22e6f294 | 443 | |
22e6f294 JH |
444 | |
445 | ||
446 | ||
447 | ||
d8129d87 | 448 | Dukhovni & Hardaker Expires February 18, 2015 [Page 8] |
a46255cd JH |
449 | \f |
450 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
22e6f294 JH |
451 | |
452 | ||
a46255cd JH |
453 | On the other hand, each trusted CA can issue certificates for any |
454 | domain. If even one of the configured CAs is compromised or operated | |
455 | by an adversary, it can subvert TLS security for all destinations. | |
456 | Any set of CAs is simultaneously both overly inclusive and not | |
457 | inclusive enough. | |
22e6f294 | 458 | |
a46255cd | 459 | 2. Identifying applicable TLSA records |
22e6f294 | 460 | |
a46255cd | 461 | 2.1. DNS considerations |
22e6f294 | 462 | |
a46255cd | 463 | 2.1.1. DNS errors, bogus and indeterminate responses |
22e6f294 JH |
464 | |
465 | An SMTP client that implements opportunistic DANE TLS per this | |
466 | specification depends critically on the integrity of DNSSEC lookups, | |
a46255cd | 467 | as discussed in Section 1.3.2. This section lists the DNS resolver |
22e6f294 JH |
468 | requirements needed to avoid downgrade attacks when using |
469 | opportunistic DANE TLS. | |
470 | ||
471 | A DNS lookup may signal an error or return a definitive answer. A | |
472 | security-aware resolver must be used for this specification. | |
473 | Security-aware resolvers will indicate the security status of a DNS | |
474 | RRset with one of four possible values defined in Section 4.3 of | |
475 | [RFC4035]: "secure", "insecure", "bogus" and "indeterminate". In | |
476 | [RFC4035] the meaning of the "indeterminate" security status is: | |
477 | ||
478 | An RRset for which the resolver is not able to determine whether | |
479 | the RRset should be signed, as the resolver is not able to obtain | |
480 | the necessary DNSSEC RRs. This can occur when the security-aware | |
481 | resolver is not able to contact security-aware name servers for | |
482 | the relevant zones. | |
483 | ||
484 | Note, the "indeterminate" security status has a conflicting | |
485 | definition in section 5 of [RFC4033]. | |
486 | ||
487 | There is no trust anchor that would indicate that a specific | |
488 | portion of the tree is secure. | |
489 | ||
a46255cd JH |
490 | To avoid further confusion, the adjective "anchorless" will be used |
491 | below to refer to domains or RRsets that are "indeterminate" in the | |
492 | [RFC4033] sense, and the term "indeterminate" will be used | |
493 | exclusively in the sense of [RFC4035]. | |
494 | ||
22e6f294 | 495 | SMTP clients following this specification SHOULD NOT distinguish |
a46255cd JH |
496 | between "insecure" and "anchorless" DNS responses. Both "insecure" |
497 | and "anchorless" RRsets MUST be handled identically: in either case | |
498 | unvalidated data for the query domain is all that is and can be | |
499 | available, and authentication using the data is impossible. In what | |
d8129d87 | 500 | follows, the term "insecure" will also include the case of |
a46255cd JH |
501 | |
502 | ||
503 | ||
d8129d87 | 504 | Dukhovni & Hardaker Expires February 18, 2015 [Page 9] |
a46255cd JH |
505 | \f |
506 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
507 | ||
508 | ||
509 | "anchorless" domains that lie in a portion of the DNS tree for which | |
510 | there is no applicable trust anchor. With the DNS root zone signed, | |
511 | we expect that validating resolvers used by Internet-facing MTAs will | |
512 | be configured with trust anchor data for the root zone, and that | |
513 | therefore "anchorless" domains should be rare in practice. | |
22e6f294 JH |
514 | |
515 | As noted in section 4.3 of [RFC4035], a security-aware DNS resolver | |
516 | MUST be able to determine whether a given non-error DNS response is | |
517 | "secure", "insecure", "bogus" or "indeterminate". It is expected | |
518 | that most security-aware stub resolvers will not signal an | |
a46255cd | 519 | "indeterminate" security status (in the sense of RFC4035) to the |
22e6f294 JH |
520 | application, and will signal a "bogus" or error result instead. If a |
521 | resolver does signal an RFC4035 "indeterminate" security status, this | |
522 | MUST be treated by the SMTP client as though a "bogus" or error | |
523 | result had been returned. | |
524 | ||
22e6f294 JH |
525 | An MTA making use of a non-validating security-aware stub resolver |
526 | MAY use the stub resolver's ability, if available, to signal DNSSEC | |
527 | validation status based on information the stub resolver has learned | |
a46255cd JH |
528 | from an upstream validating recursive resolver. Security-Oblivious |
529 | stub-resolvers MUST NOT be used. In accordance with section 4.9.3 of | |
530 | [RFC4035]: | |
22e6f294 JH |
531 | |
532 | ... a security-aware stub resolver MUST NOT place any reliance on | |
533 | signature validation allegedly performed on its behalf, except | |
534 | when the security-aware stub resolver obtained the data in question | |
535 | from a trusted security-aware recursive name server via a secure | |
536 | channel. | |
537 | ||
538 | To avoid much repetition in the text below, we will pause to explain | |
539 | the handling of "bogus" or "indeterminate" DNSSEC query responses. | |
540 | These are not necessarily the result of a malicious actor; they can, | |
541 | for example, occur when network packets are corrupted or lost in | |
542 | transit. Therefore, "bogus" or "indeterminate" replies are equated | |
543 | in this memo with lookup failure. | |
544 | ||
545 | There is an important non-failure condition we need to highlight in | |
546 | addition to the obvious case of the DNS client obtaining a non-empty | |
547 | "secure" or "insecure" RRset of the requested type. Namely, it is | |
548 | not an error when either "secure" or "insecure" non-existence is | |
549 | determined for the requested data. When a DNSSEC response with a | |
550 | validation status that is either "secure" or "insecure" reports | |
551 | either no records of the requested type or non-existence of the query | |
552 | domain, the response is not a DNS error condition. The DNS client | |
553 | has not been left without an answer; it has learned that records of | |
554 | the requested type do not exist. | |
555 | ||
a46255cd JH |
556 | |
557 | ||
558 | ||
559 | ||
d8129d87 | 560 | Dukhovni & Hardaker Expires February 18, 2015 [Page 10] |
a46255cd JH |
561 | \f |
562 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
563 | ||
564 | ||
22e6f294 JH |
565 | Security-aware stub resolvers will, of course, also signal DNS lookup |
566 | errors in other cases, for example when processing a "ServFail" | |
567 | RCODE, which will not have an associated DNSSEC status. All lookup | |
568 | errors are treated the same way by this specification, regardless of | |
569 | whether they are from a "bogus" or "indeterminate" DNSSEC status or | |
570 | from a more generic DNS error: the information that was requested | |
571 | cannot be obtained by the security-aware resolver at this time. A | |
572 | lookup error is thus a failure to obtain the relevant RRset if it | |
573 | exists, or to determine that no such RRset exists when it does not. | |
574 | ||
575 | In contrast to a "bogus" or an "indeterminate" response, an | |
576 | "insecure" DNSSEC response is not an error, rather it indicates that | |
577 | the target DNS zone is either securely opted out of DNSSEC validation | |
578 | or is not connected with the DNSSEC trust anchors being used. | |
579 | Insecure results will leave the SMTP client with degraded channel | |
580 | security, but do not stand in the way of message delivery. See | |
581 | section Section 2.2 for further details. | |
582 | ||
22e6f294 JH |
583 | 2.1.2. DNS error handling |
584 | ||
585 | When a DNS lookup failure (error or "bogus" or "indeterminate" as | |
586 | defined above) prevents an SMTP client from determining which SMTP | |
587 | server or servers it should connect to, message delivery MUST be | |
588 | delayed. This naturally includes, for example, the case when a | |
589 | "bogus" or "indeterminate" response is encountered during MX | |
590 | resolution. When multiple MX hostnames are obtained from a | |
591 | successful MX lookup, but a later DNS lookup failure prevents network | |
592 | address resolution for a given MX hostname, delivery may proceed via | |
593 | any remaining MX hosts. | |
594 | ||
595 | When a particular SMTP server is securely identified as the delivery | |
596 | destination, a set of DNS lookups (Section 2.2) MUST be performed to | |
597 | locate any related TLSA records. If any DNS queries used to locate | |
598 | TLSA records fail (be it due to "bogus" or "indeterminate" records, | |
599 | timeouts, malformed replies, ServFails, etc.), then the SMTP client | |
600 | MUST treat that server as unreachable and MUST NOT deliver the | |
601 | message via that server. If no servers are reachable, delivery is | |
602 | delayed. | |
603 | ||
604 | In what follows, we will only describe what happens when all relevant | |
605 | DNS queries succeed. If any DNS failure occurs, the SMTP client MUST | |
606 | behave as described in this section, by skipping the problem SMTP | |
607 | server, or the problem destination. Queries for candidate TLSA | |
608 | records are explicitly part of "all relevant DNS queries" and SMTP | |
609 | clients MUST NOT continue to connect to an SMTP server or destination | |
610 | whose TLSA record lookup fails. | |
611 | ||
a46255cd JH |
612 | |
613 | ||
614 | ||
615 | ||
d8129d87 | 616 | Dukhovni & Hardaker Expires February 18, 2015 [Page 11] |
a46255cd JH |
617 | \f |
618 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
619 | ||
620 | ||
22e6f294 JH |
621 | 2.1.3. Stub resolver considerations |
622 | ||
a46255cd JH |
623 | SMTP clients that employ opportunistic DANE TLS to secure connections |
624 | to SMTP servers MUST NOT use Security-Oblivious stub-resolvers. | |
625 | ||
22e6f294 | 626 | A note about DNAME aliases: a query for a domain name whose ancestor |
a46255cd | 627 | domain is a DNAME alias returns the DNAME RR for the ancestor domain |
22e6f294 JH |
628 | along with a CNAME that maps the query domain to the corresponding |
629 | sub-domain of the target domain of the DNAME alias [RFC6672]. | |
630 | Therefore, whenever we speak of CNAME aliases, we implicitly allow | |
631 | for the possibility that the alias in question is the result of an | |
632 | ancestor domain DNAME record. Consequently, no explicit support for | |
a46255cd | 633 | DNAME records is needed in SMTP software; it is sufficient to process |
22e6f294 JH |
634 | the resulting CNAME aliases. DNAME records only require special |
635 | processing in the validating stub-resolver library that checks the | |
636 | integrity of the combined DNAME + CNAME reply. When DNSSEC | |
637 | validation is handled by a local caching resolver, rather than the | |
638 | MTA itself, even that part of the DNAME support logic is outside the | |
639 | MTA. | |
640 | ||
641 | When a stub resolver returns a response containing a CNAME alias that | |
642 | does not also contain the corresponding query results for the target | |
22e6f294 JH |
643 | of the alias, the SMTP client will need to repeat the query at the |
644 | target of the alias, and should do so recursively up to some | |
645 | configured or implementation-dependent recursion limit. If at any | |
646 | stage of CNAME expansion an error is detected, the lookup of the | |
647 | original requested records MUST be considered to have failed. | |
648 | ||
649 | Whether a chain of CNAME records was returned in a single stub | |
650 | resolver response or via explicit recursion by the SMTP client, if at | |
651 | any stage of recursive expansion an "insecure" CNAME record is | |
652 | encountered, then it and all subsequent results (in particular, the | |
653 | final result) MUST be considered "insecure" regardless of whether any | |
654 | earlier CNAME records leading to the "insecure" record were "secure". | |
655 | ||
a46255cd JH |
656 | Note that a security-aware non-validating stub resolver may return to |
657 | the SMTP client an "insecure" reply received from a validating | |
658 | recursive resolver that contains a CNAME record along with additional | |
659 | answers recursively obtained starting at the target of the CNAME. In | |
660 | this case, the only possible conclusion is that some record in the | |
661 | set of records returned is "insecure", and it is in fact possible | |
662 | that the initial CNAME record and a subset of the subsequent records | |
663 | are "secure". | |
22e6f294 JH |
664 | |
665 | If the SMTP client needs to determine the security status of the DNS | |
a46255cd | 666 | zone containing the initial CNAME record, it may need to issue a |
22e6f294 JH |
667 | separate query of type "CNAME" that returns only the initial CNAME |
668 | record. In particular in Section 2.2.2 when insecure A or AAAA | |
a46255cd JH |
669 | |
670 | ||
671 | ||
d8129d87 | 672 | Dukhovni & Hardaker Expires February 18, 2015 [Page 12] |
a46255cd JH |
673 | \f |
674 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
675 | ||
676 | ||
22e6f294 JH |
677 | records are found for an SMTP server via a CNAME alias, it may be |
678 | necessary to perform an additional CNAME query to determine whether | |
679 | the DNS zone in which the alias is published is signed. | |
680 | ||
681 | 2.2. TLS discovery | |
682 | ||
683 | As noted previously (in Section 1.3.1), opportunistic TLS with SMTP | |
684 | servers that advertise TLS support via STARTTLS is subject to an MITM | |
685 | downgrade attack. Also some SMTP servers that are not, in fact, TLS | |
686 | capable erroneously advertise STARTTLS by default and clients need to | |
687 | be prepared to retry cleartext delivery after STARTTLS fails. In | |
688 | contrast, DNSSEC validated TLSA records MUST NOT be published for | |
689 | servers that do not support TLS. Clients can safely interpret their | |
690 | presence as a commitment by the server operator to implement TLS and | |
691 | STARTTLS. | |
692 | ||
693 | This memo defines four actions to be taken after the search for a | |
694 | TLSA record returns secure usable results, secure unusable results, | |
695 | insecure or no results or an error signal. The term "usable" in this | |
696 | context is in the sense of Section 4.1 of [RFC6698]. Specifically, | |
697 | if the DNS lookup for a TLSA record returns: | |
698 | ||
22e6f294 JH |
699 | A secure TLSA RRset with at least one usable record: A connection to |
700 | the MTA MUST be made using authenticated and encrypted TLS, using | |
701 | the techniques discussed in the rest of this document. Failure to | |
702 | establish an authenticated TLS connection MUST result in falling | |
703 | back to the next SMTP server or delayed delivery. | |
704 | ||
a46255cd | 705 | A secure non-empty TLSA RRset where all the records are unusable: A |
22e6f294 JH |
706 | connection to the MTA MUST be made via TLS, but authentication is |
707 | not required. Failure to establish an encrypted TLS connection | |
708 | MUST result in falling back to the next SMTP server or delayed | |
709 | delivery. | |
710 | ||
711 | An insecure TLSA RRset or DNSSEC validated proof-of-non-existent TLSA | |
712 | records: | |
713 | A connection to the MTA SHOULD be made using (pre-DANE) | |
714 | opportunistic TLS, this includes using cleartext delivery when the | |
715 | remote SMTP server does not appear to support TLS. The MTA MAY | |
716 | retry in cleartext when delivery via TLS fails either during the | |
717 | handshake or even during data transfer. | |
718 | ||
719 | Any lookup error: Lookup errors, including "bogus" and | |
720 | "indeterminate", as explained in Section 2.1.1 MUST result in | |
721 | falling back to the next SMTP server or delayed delivery. | |
722 | ||
723 | An SMTP client MAY be configured to require DANE verified delivery | |
724 | for some destinations. We will call such a configuration "mandatory | |
a46255cd JH |
725 | |
726 | ||
727 | ||
d8129d87 | 728 | Dukhovni & Hardaker Expires February 18, 2015 [Page 13] |
a46255cd JH |
729 | \f |
730 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
731 | ||
732 | ||
22e6f294 JH |
733 | DANE TLS". With mandatory DANE TLS, delivery proceeds only when |
734 | "secure" TLSA records are used to establish an encrypted and | |
735 | authenticated TLS channel with the SMTP server. | |
736 | ||
737 | When the original next-hop destination is an address literal, rather | |
738 | than a DNS domain, DANE TLS does not apply. Delivery proceeds using | |
739 | any relevant security policy configured by the MTA administrator. | |
740 | Similarly, when an MX RRset incorrectly lists a network address in | |
a46255cd | 741 | lieu of an MX hostname, if an MTA chooses to connect to the network |
d8129d87 | 742 | address in the non-conformant MX record, DANE TLSA does not apply for |
a46255cd | 743 | such a connection. |
22e6f294 JH |
744 | |
745 | In the subsections that follow we explain how to locate the SMTP | |
746 | servers and the associated TLSA records for a given next-hop | |
747 | destination domain. We also explain which name or names are to be | |
748 | used in identity checks of the SMTP server certificate. | |
749 | ||
750 | 2.2.1. MX resolution | |
751 | ||
752 | In this section we consider next-hop domains that are subject to MX | |
753 | resolution and have MX records. The TLSA records and the associated | |
754 | base domain are derived separately for each MX hostname that is used | |
755 | to attempt message delivery. DANE TLS can authenticate message | |
22e6f294 JH |
756 | delivery to the intended next-hop domain only when the MX records are |
757 | obtained securely via a DNSSEC validated lookup. | |
758 | ||
759 | MX records MUST be sorted by preference; an MX hostname with a worse | |
760 | (numerically higher) MX preference that has TLSA records MUST NOT | |
761 | preempt an MX hostname with a better (numerically lower) preference | |
762 | that has no TLSA records. In other words, prevention of delivery | |
763 | loops by obeying MX preferences MUST take precedence over channel | |
764 | security considerations. Even with two equal-preference MX records, | |
765 | an MTA is not obligated to choose the MX hostname that offers more | |
766 | security. Domains that want secure inbound mail delivery need to | |
767 | ensure that all their SMTP servers and MX records are configured | |
768 | accordingly. | |
769 | ||
770 | In the language of [RFC5321] Section 5.1, the original next-hop | |
771 | domain is the "initial name". If the MX lookup of the initial name | |
772 | results in a CNAME alias, the MTA replaces the initial name with the | |
773 | resulting name and performs a new lookup with the new name. MTAs | |
774 | typically support recursion in CNAME expansion, so this replacement | |
a46255cd JH |
775 | is performed repeatedly (up to the MTA's recursion limit) until the |
776 | ultimate non-CNAME domain is found. | |
22e6f294 JH |
777 | |
778 | If the MX RRset (or any CNAME leading to it) is "insecure" (see | |
779 | Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via | |
780 | pre-DANE opportunistic TLS. That said, the protocol in this memo is | |
a46255cd JH |
781 | |
782 | ||
783 | ||
d8129d87 | 784 | Dukhovni & Hardaker Expires February 18, 2015 [Page 14] |
a46255cd JH |
785 | \f |
786 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
787 | ||
788 | ||
22e6f294 JH |
789 | an "opportunistic security" protocol, meaning that it strives to |
790 | communicate with each peer as securely as possible, while maintaining | |
791 | broad interoperability. Therefore, the SMTP client MAY proceed to | |
792 | use DANE TLS (as described in Section 2.2.2 below) even with MX hosts | |
793 | obtained via an "insecure" MX RRset. For example, when a hosting | |
794 | provider has a signed DNS zone and publishes TLSA records for its | |
795 | SMTP servers, hosted domains that are not signed may still benefit | |
796 | from the provider's TLSA records. Deliveries via the provider's SMTP | |
797 | servers will not be subject to active attacks when sending SMTP | |
798 | clients elect to make use of the provider's TLSA records. | |
799 | ||
800 | When the MX records are not (DNSSEC) signed, an active attacker can | |
801 | redirect SMTP clients to MX hosts of his choice. Such redirection is | |
802 | tamper-evident when SMTP servers found via "insecure" MX records are | |
803 | recorded as the next-hop relay in the MTA delivery logs in their | |
804 | original (rather than CNAME expanded) form. Sending MTAs SHOULD log | |
805 | unexpanded MX hostnames when these result from insecure MX lookups. | |
806 | Any successful authentication via an insecurely determined MX host | |
807 | MUST NOT be misrepresented in the mail logs as secure delivery to the | |
808 | intended next-hop domain. When DANE TLS is mandatory (Section 6) for | |
809 | a given destination, delivery MUST be delayed when the MX RRset is | |
810 | not "secure". | |
811 | ||
22e6f294 JH |
812 | Otherwise, assuming no DNS errors (Section 2.1.1), the MX RRset is |
813 | "secure", and the SMTP client MUST treat each MX hostname as a | |
814 | separate non-MX destination for opportunistic DANE TLS as described | |
815 | in Section 2.2.2. When, for a given MX hostname, no TLSA records are | |
816 | found, or only "insecure" TLSA records are found, DANE TLSA is not | |
817 | applicable with the SMTP server in question and delivery proceeds to | |
818 | that host as with pre-DANE opportunistic TLS. To avoid downgrade | |
819 | attacks, any errors during TLSA lookups MUST, as explained in | |
820 | Section 2.1.1, cause the SMTP server in question to be treated as | |
821 | unreachable. | |
822 | ||
823 | 2.2.2. Non-MX destinations | |
824 | ||
825 | This section describes the algorithm used to locate the TLSA records | |
826 | and associated TLSA base domain for an input domain not subject to MX | |
827 | resolution. Such domains include: | |
828 | ||
829 | o Each MX hostname used in a message delivery attempt for an | |
830 | original next-hop destination domain subject to MX resolution. | |
831 | Note, MTAs are not obligated to support CNAME expansion of MX | |
832 | hostnames. | |
833 | ||
834 | o Any administrator configured relay hostname, not subject to MX | |
835 | resolution. This frequently involves configuration set by the MTA | |
836 | administrator to handle some or all mail. | |
837 | ||
a46255cd JH |
838 | |
839 | ||
d8129d87 | 840 | Dukhovni & Hardaker Expires February 18, 2015 [Page 15] |
a46255cd JH |
841 | \f |
842 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
843 | ||
844 | ||
22e6f294 JH |
845 | o A next-hop destination domain subject to MX resolution that has no |
846 | MX records. In this case the domain's name is implicitly also its | |
847 | sole SMTP server name. | |
848 | ||
849 | Note that DNS queries with type TLSA are mishandled by load balancing | |
850 | nameservers that serve the MX hostnames of some large email | |
851 | providers. The DNS zones served by these nameservers are not signed | |
852 | and contain no TLSA records, but queries for TLSA records fail, | |
853 | rather than returning the non-existence of the requested TLSA | |
854 | records. | |
855 | ||
856 | To avoid problems delivering mail to domains whose SMTP servers are | |
857 | served by the problem nameservers the SMTP client MUST perform any A | |
858 | and/or AAAA queries for the destination before attempting to locate | |
859 | the associated TLSA records. This lookup is needed in any case to | |
860 | determine whether the destination domain is reachable and the DNSSEC | |
861 | validation status of the chain of CNAME queries required to reach the | |
862 | ultimate address records. | |
863 | ||
864 | If no address records are found, the destination is unreachable. If | |
865 | address records are found, but the DNSSEC validation status of the | |
866 | first query response is "insecure" (see Section 2.1.3), the SMTP | |
22e6f294 JH |
867 | client SHOULD NOT proceed to search for any associated TLSA records. |
868 | With the problem domains, TLSA queries will lead to DNS lookup errors | |
869 | and cause messages to be consistently delayed and ultimately returned | |
870 | to the sender. We don't expect to find any "secure" TLSA records | |
871 | associated with a TLSA base domain that lies in an unsigned DNS zone. | |
872 | Therefore, skipping TLSA lookups in this case will also reduce | |
873 | latency with no detrimental impact on security. | |
874 | ||
875 | If the A and/or AAAA lookup of the "initial name" yields a CNAME, we | |
876 | replace it with the resulting name as if it were the initial name and | |
877 | perform a lookup again using the new name. This replacement is | |
a46255cd | 878 | performed recursively (up to the MTA's recursion limit). |
22e6f294 JH |
879 | |
880 | We consider the following cases for handling a DNS response for an A | |
881 | or AAAA DNS lookup: | |
882 | ||
883 | Not found: When the DNS queries for A and/or AAAA records yield | |
884 | neither a list of addresses nor a CNAME (or CNAME expansion is not | |
885 | supported) the destination is unreachable. | |
886 | ||
a46255cd JH |
887 | |
888 | ||
889 | ||
890 | ||
891 | ||
892 | ||
893 | ||
894 | ||
895 | ||
d8129d87 | 896 | Dukhovni & Hardaker Expires February 18, 2015 [Page 16] |
a46255cd JH |
897 | \f |
898 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
899 | ||
900 | ||
22e6f294 JH |
901 | Non-CNAME: The answer is not a CNAME alias. If the address RRset |
902 | is "secure", TLSA lookups are performed as described in | |
903 | Section 2.2.3 with the initial name as the candidate TLSA base | |
904 | domain. If no "secure" TLSA records are found, DANE TLS is not | |
905 | applicable and mail delivery proceeds with pre-DANE opportunistic | |
906 | TLS (which, being best-effort, degrades to cleartext delivery when | |
907 | STARTTLS is not available or the TLS handshake fails). | |
908 | ||
909 | Insecure CNAME: The input domain is a CNAME alias, but the ultimate | |
910 | network address RRset is "insecure" (see Section 2.1.1). If the | |
911 | initial CNAME response is also "insecure", DANE TLS does not | |
912 | apply. Otherwise, this case is treated just like the non-CNAME | |
913 | case above, where a search is performed for a TLSA record with the | |
914 | original input domain as the candidate TLSA base domain. | |
915 | ||
916 | Secure CNAME: The input domain is a CNAME alias, and the ultimate | |
917 | network address RRset is "secure" (see Section 2.1.1). Two | |
918 | candidate TLSA base domains are tried: the fully CNAME-expanded | |
919 | initial name and, failing that, then the initial name itself. | |
920 | ||
22e6f294 JH |
921 | In summary, if it is possible to securely obtain the full, CNAME- |
922 | expanded, DNSSEC-validated address records for the input domain, then | |
923 | that name is the preferred TLSA base domain. Otherwise, the | |
924 | unexpanded input-MX domain is the candidate TLSA base domain. When | |
925 | no "secure" TLSA records are found at either the CNAME-expanded or | |
926 | unexpanded domain, then DANE TLS does not apply for mail delivery via | |
927 | the input domain in question. And, as always, errors, bogus or | |
928 | indeterminate results for any query in the process MUST result in | |
929 | delaying or abandoning delivery. | |
930 | ||
931 | 2.2.3. TLSA record lookup | |
932 | ||
933 | Each candidate TLSA base domain (the original or fully CNAME-expanded | |
934 | name of a non-MX destination or a particular MX hostname of an MX | |
935 | destination) is in turn prefixed with service labels of the form | |
936 | "_<port>._tcp". The resulting domain name is used to issue a DNSSEC | |
937 | query with the query type set to TLSA ([RFC6698] Section 7.1). | |
938 | ||
939 | For SMTP, the destination TCP port is typically 25, but this may be | |
940 | different with custom routes specified by the MTA administrator in | |
941 | which case the SMTP client MUST use the appropriate number in the | |
942 | "_<port>" prefix in place of "_25". If, for example, the candidate | |
943 | base domain is "mx.example.com", and the SMTP connection is to port | |
944 | 25, the TLSA RRset is obtained via a DNSSEC query of the form: | |
945 | ||
946 | _25._tcp.mx.example.com. IN TLSA ? | |
947 | ||
a46255cd JH |
948 | |
949 | ||
950 | ||
951 | ||
d8129d87 | 952 | Dukhovni & Hardaker Expires February 18, 2015 [Page 17] |
a46255cd JH |
953 | \f |
954 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
955 | ||
956 | ||
22e6f294 JH |
957 | The query response may be a CNAME, or the actual TLSA RRset. If the |
958 | response is a CNAME, the SMTP client (through the use of its | |
959 | security-aware stub resolver) restarts the TLSA query at the target | |
960 | domain, following CNAMEs as appropriate and keeping track of whether | |
961 | the entire chain is "secure". If any "insecure" records are | |
962 | encountered, or the TLSA records don't exist, the next candidate TLSA | |
a46255cd | 963 | base domain is tried instead. |
22e6f294 JH |
964 | |
965 | If the ultimate response is a "secure" TLSA RRset, then the candidate | |
966 | TLSA base domain will be the actual TLSA base domain and the TLSA | |
967 | RRset will constitute the TLSA records for the destination. If none | |
968 | of the candidate TLSA base domains yield "secure" TLSA records then | |
969 | delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients | |
970 | MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades | |
971 | or even to skip SMTP servers that fail authentication, but MUST NOT | |
972 | misrepresent authentication success as either a secure connection to | |
973 | the SMTP server or as a secure delivery to the intended next-hop | |
974 | domain. | |
975 | ||
976 | TLSA record publishers may leverage CNAMEs to reference a single | |
977 | authoritative TLSA RRset specifying a common Certification Authority | |
22e6f294 JH |
978 | or a common end entity certificate to be used with multiple TLS |
979 | services. Such CNAME expansion does not change the SMTP client's | |
980 | notion of the TLSA base domain; thus, when _25._tcp.mx.example.com is | |
981 | a CNAME, the base domain remains mx.example.com and this is still the | |
982 | reference identifier used together with the next-hop domain in peer | |
983 | certificate name checks. | |
984 | ||
a46255cd | 985 | Note that shared end entity certificate associations expose the |
22e6f294 JH |
986 | publishing domain to substitution attacks, where an MITM attacker can |
987 | reroute traffic to a different server that shares the same end entity | |
a46255cd JH |
988 | certificate. Such shared end entity TLSA records SHOULD be avoided |
989 | unless the servers in question are functionally equivalent or employ | |
990 | mutually incompatible protocols (an active attacker gains nothing by | |
991 | diverting client traffic from one such server to another). | |
22e6f294 | 992 | |
a46255cd JH |
993 | A better example, employing a shared trust anchor rather than shared |
994 | end-entity certificates, is illustrated by the DNSSEC validated | |
995 | records below: | |
22e6f294 JH |
996 | |
997 | example.com. IN MX 0 mx1.example.com. | |
998 | example.com. IN MX 0 mx2.example.com. | |
a46255cd JH |
999 | _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com. |
1000 | _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com. | |
1001 | tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c149a... | |
22e6f294 JH |
1002 | |
1003 | The SMTP servers mx1.example.com and mx2.example.com will be expected | |
1004 | to have certificates issued under a common trust anchor, but each MX | |
a46255cd JH |
1005 | |
1006 | ||
1007 | ||
d8129d87 | 1008 | Dukhovni & Hardaker Expires February 18, 2015 [Page 18] |
a46255cd JH |
1009 | \f |
1010 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1011 | ||
1012 | ||
22e6f294 JH |
1013 | hostname's TLSA base domain remains unchanged despite the above CNAME |
1014 | records. Correspondingly, each SMTP server will be associated with a | |
1015 | pair of reference identifiers consisting of its hostname plus the | |
1016 | next-hop domain "example.com". | |
1017 | ||
1018 | If, during TLSA resolution (including possible CNAME indirection), at | |
1019 | least one "secure" TLSA record is found (even if not usable because | |
1020 | it is unsupported by the implementation or support is | |
1021 | administratively disabled), then the corresponding host has signaled | |
1022 | its commitment to implement TLS. The SMTP client MUST NOT deliver | |
1023 | mail via the corresponding host unless a TLS session is negotiated | |
1024 | via STARTTLS. This is required to avoid MITM STARTTLS downgrade | |
1025 | attacks. | |
1026 | ||
1027 | As noted previously (in Section Section 2.2.2), when no "secure" TLSA | |
1028 | records are found at the fully CNAME-expanded name, the original | |
1029 | unexpanded name MUST be tried instead. This supports customers of | |
1030 | hosting providers where the provider's zone cannot be validated with | |
1031 | DNSSEC, but the customer has shared appropriate key material with the | |
1032 | hosting provider to enable TLS via SNI. Intermediate names that | |
1033 | arise during CNAME expansion that are neither the original, nor the | |
1034 | final name, are never candidate TLSA base domains, even if "secure". | |
1035 | ||
22e6f294 JH |
1036 | 3. DANE authentication |
1037 | ||
1038 | This section describes which TLSA records are applicable to SMTP | |
1039 | opportunistic DANE TLS and how to apply such records to authenticate | |
1040 | the SMTP server. With opportunistic DANE TLS, both the TLS support | |
1041 | implied by the presence of DANE TLSA records and the verification | |
1042 | parameters necessary to authenticate the TLS peer are obtained | |
1043 | together. In contrast to protocols where channel security policy is | |
1044 | set exclusively by the client, authentication via this protocol is | |
1045 | expected to be less prone to connection failure caused by | |
1046 | incompatible configuration of the client and server. | |
1047 | ||
1048 | 3.1. TLSA certificate usages | |
1049 | ||
1050 | The DANE TLSA specification [RFC6698] defines multiple TLSA RR types | |
1051 | via combinations of 3 numeric parameters. The numeric values of | |
a46255cd JH |
1052 | these parameters were later given symbolic names in [RFC7218]. The |
1053 | rest of the TLSA record is the "certificate association data field", | |
1054 | which specifies the full or digest value of a certificate or public | |
1055 | key. The parameters are: | |
1056 | ||
1057 | ||
1058 | ||
1059 | ||
1060 | ||
1061 | ||
1062 | ||
1063 | ||
d8129d87 | 1064 | Dukhovni & Hardaker Expires February 18, 2015 [Page 19] |
a46255cd JH |
1065 | \f |
1066 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1067 | ||
22e6f294 JH |
1068 | |
1069 | The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698] | |
a46255cd JH |
1070 | specifies four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and |
1071 | DANE-EE(3). There is an additional private-use value: | |
1072 | PrivCert(255). All other values are reserved for use by future | |
1073 | specifications. | |
22e6f294 | 1074 | |
a46255cd JH |
1075 | The selector field: Section 2.1.2 of [RFC6698] specifies two values: |
1076 | Cert(0) and SPKI(1). There is an additional private-use value: | |
22e6f294 JH |
1077 | PrivSel(255). All other values are reserved for use by future |
1078 | specifications. | |
1079 | ||
a46255cd JH |
1080 | The matching type field: Section 2.1.3 of [RFC6698] specifies three |
1081 | values: Full(0), SHA2-256(1) and SHA2-512(2). There is an | |
1082 | additional private-use value: PrivMatch(255). All other values | |
1083 | are reserved for use by future specifications. | |
22e6f294 JH |
1084 | |
1085 | We may think of TLSA Certificate Usage values 0 through 3 as a | |
1086 | combination of two one-bit flags. The low bit chooses between trust | |
1087 | anchor (TA) and end entity (EE) certificates. The high bit chooses | |
1088 | between public PKI issued and domain-issued certificates. | |
1089 | ||
1090 | The selector field specifies whether the TLSA RR matches the whole | |
1091 | certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1). The | |
a46255cd JH |
1092 | subjectPublicKeyInfo is an ASN.1 DER ([X.690]) encoding of the |
1093 | certificate's algorithm id, any parameters and the public key data. | |
22e6f294 JH |
1094 | |
1095 | The matching type field specifies how the TLSA RR Certificate | |
1096 | Association Data field is to be compared with the certificate or | |
22e6f294 JH |
1097 | public key. A value of Full(0) means an exact match: the full DER |
1098 | encoding of the certificate or public key is given in the TLSA RR. A | |
1099 | value of SHA2-256(1) means that the association data matches the | |
1100 | SHA2-256 digest of the certificate or public key, and likewise | |
1101 | SHA2-512(2) means a SHA2-512 digest is used. | |
1102 | ||
1103 | Since opportunistic DANE TLS will be used by non-interactive MTAs, | |
1104 | with no user to "press OK" when authentication fails, reliability of | |
1105 | peer authentication is paramount. Server operators are advised to | |
1106 | publish TLSA records that are least likely to fail authentication due | |
1107 | to interoperability or operational problems. Because DANE TLS relies | |
1108 | on coordinated changes to DNS and SMTP server settings, the best | |
1109 | choice of records to publish will depend on site-specific practices. | |
1110 | ||
a46255cd JH |
1111 | |
1112 | ||
1113 | ||
1114 | ||
1115 | ||
1116 | ||
1117 | ||
1118 | ||
1119 | ||
d8129d87 | 1120 | Dukhovni & Hardaker Expires February 18, 2015 [Page 20] |
a46255cd JH |
1121 | \f |
1122 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1123 | ||
1124 | ||
22e6f294 JH |
1125 | The certificate usage element of a TLSA record plays a critical role |
1126 | in determining how the corresponding certificate association data | |
1127 | field is used to authenticate server's certificate chain. The next | |
1128 | two subsections explain the process for certificate usages DANE-EE(3) | |
1129 | and DANE-TA(2). The third subsection briefly explains why | |
1130 | certificate usages PKIX-TA(0) and PKIX-EE(1) are not applicable with | |
1131 | opportunistic DANE TLS. | |
1132 | ||
1133 | In summary, we recommend the use of either "DANE-EE(3) SPKI(1) | |
1134 | SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records | |
1135 | depending on site needs. Other combinations of TLSA parameters are | |
1136 | either explicitly unsupported, or offer little to recommend them over | |
1137 | these two. | |
1138 | ||
1139 | The mandatory to support digest algorithm in [RFC6698] is | |
1140 | SHA2-256(1). When the server's TLSA RRset includes records with a | |
1141 | matching type indicating a digest record (i.e., a value other than | |
1142 | Full(0)), a TLSA record with a SHA2-256(1) matching type SHOULD be | |
1143 | provided along with any other digest published, since some SMTP | |
1144 | clients may support only SHA2-256(1). If at some point the SHA2-256 | |
1145 | digest algorithm is tarnished by new cryptanalytic attacks, | |
1146 | publishers will need to include an appropriate stronger digest in | |
1147 | their TLSA records, initially along with, and ultimately in place of, | |
1148 | SHA2-256. | |
1149 | ||
1150 | 3.1.1. Certificate usage DANE-EE(3) | |
1151 | ||
1152 | Authentication via certificate usage DANE-EE(3) TLSA records involves | |
1153 | simply checking that the server's leaf certificate matches the TLSA | |
1154 | record. In particular the binding of the server public key to its | |
1155 | name is based entirely on the TLSA record association. The server | |
1156 | MUST be considered authenticated even if none of the names in the | |
1157 | certificate match the client's reference identity for the server. | |
1158 | ||
22e6f294 JH |
1159 | Similarly, the expiration date of the server certificate MUST be |
1160 | ignored, the validity period of the TLSA record key binding is | |
1161 | determined by the validity interval of the TLSA record DNSSEC | |
1162 | signature. | |
1163 | ||
1164 | With DANE-EE(3) servers need not employ SNI (may ignore the client's | |
1165 | SNI message) even when the server is known under independent names | |
1166 | that would otherwise require separate certificates. It is instead | |
1167 | sufficient for the TLSA RRsets for all the domains in question to | |
1168 | match the server's default certificate. Of course with SMTP servers | |
1169 | it is simpler still to publish the same MX hostname for all the | |
1170 | hosted domains. | |
1171 | ||
a46255cd JH |
1172 | |
1173 | ||
1174 | ||
1175 | ||
d8129d87 | 1176 | Dukhovni & Hardaker Expires February 18, 2015 [Page 21] |
a46255cd JH |
1177 | \f |
1178 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1179 | ||
1180 | ||
22e6f294 JH |
1181 | For domains where it is practical to make coordinated changes in DNS |
1182 | TLSA records during SMTP server key rotation, it is often best to | |
1183 | publish end-entity DANE-EE(3) certificate associations. DANE-EE(3) | |
1184 | certificates don't suddenly stop working when leaf or intermediate | |
1185 | certificates expire, and don't fail when the server operator neglects | |
1186 | to configure all the required issuer certificates in the server | |
1187 | certificate chain. | |
1188 | ||
1189 | TLSA records published for SMTP servers SHOULD, in most cases, be | |
1190 | "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE | |
1191 | implementations are required to support SHA2-256, this record type | |
1192 | works for all clients and need not change across certificate renewals | |
1193 | with the same key. | |
1194 | ||
1195 | 3.1.2. Certificate usage DANE-TA(2) | |
1196 | ||
1197 | Some domains may prefer to avoid the operational complexity of | |
1198 | publishing unique TLSA RRs for each TLS service. If the domain | |
1199 | employs a common issuing Certification Authority to create | |
1200 | certificates for multiple TLS services, it may be simpler to publish | |
1201 | the issuing authority as a trust anchor (TA) for the certificate | |
1202 | chains of all relevant services. The TLSA query domain (TLSA base | |
1203 | domain with port and protocol prefix labels) for each service issued | |
1204 | by the same TA may then be set to a CNAME alias that points to a | |
1205 | common TLSA RRset that matches the TA. For example: | |
1206 | ||
1207 | example.com. IN MX 0 mx1.example.com. | |
1208 | example.com. IN MX 0 mx2.example.com. | |
a46255cd JH |
1209 | _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com. |
1210 | _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com. | |
1211 | tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14.... | |
22e6f294 JH |
1212 | |
1213 | With usage DANE-TA(2) the server certificates will need to have names | |
1214 | that match one of the client's reference identifiers (see [RFC6125]). | |
1215 | The server MAY employ SNI to select the appropriate certificate to | |
1216 | present to the client. | |
1217 | ||
1218 | SMTP servers that rely on certificate usage DANE-TA(2) TLSA records | |
1219 | for TLS authentication MUST include the TA certificate as part of the | |
1220 | certificate chain presented in the TLS handshake server certificate | |
1221 | message even when it is a self-signed root certificate. At this | |
1222 | time, many SMTP servers are not configured with a comprehensive list | |
1223 | of trust anchors, nor are they expected to at any point in the | |
1224 | future. Some MTAs will ignore all locally trusted certificates when | |
1225 | processing usage DANE-TA(2) TLSA records. Thus even when the TA | |
1226 | happens to be a public Certification Authority known to the SMTP | |
1227 | client, authentication is likely to fail unless the TA certificate is | |
1228 | included in the TLS server certificate message. | |
1229 | ||
a46255cd JH |
1230 | |
1231 | ||
d8129d87 | 1232 | Dukhovni & Hardaker Expires February 18, 2015 [Page 22] |
a46255cd JH |
1233 | \f |
1234 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1235 | ||
1236 | ||
22e6f294 JH |
1237 | TLSA records with selector Full(0) are discouraged. While these |
1238 | potentially obviate the need to transmit the TA certificate in the | |
1239 | TLS server certificate message, client implementations may not be | |
1240 | able to augment the server certificate chain with the data obtained | |
1241 | from DNS, especially when the TLSA record supplies a bare key | |
1242 | (selector SPKI(1)). Since the server will need to transmit the TA | |
1243 | certificate in any case, server operators SHOULD publish TLSA records | |
1244 | with a selector other than Full(0) and avoid potential | |
1245 | interoperability issues with large TLSA records containing full | |
1246 | certificates or keys. | |
1247 | ||
1248 | TLSA Publishers employing DANE-TA(2) records SHOULD publish records | |
1249 | with a selector of Cert(0). Such TLSA records are associated with | |
1250 | the whole trust anchor certificate, not just with the trust anchor | |
1251 | public key. In particular, the SMTP client SHOULD then apply any | |
1252 | relevant constraints from the trust anchor certificate, such as, for | |
1253 | example, path length constraints. | |
1254 | ||
1255 | While a selector of SPKI(1) may also be employed, the resulting TLSA | |
1256 | record will not specify the full trust anchor certificate content, | |
1257 | and elements of the trust anchor certificate other than the public | |
1258 | key become mutable. This may, for example, allow a subsidiary CA to | |
1259 | issue a chain that violates the trust anchor's path length or name | |
1260 | constraints. | |
1261 | ||
1262 | 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) | |
1263 | ||
1264 | As noted in the introduction, SMTP clients cannot, without relying on | |
1265 | DNSSEC for secure MX records and DANE for STARTTLS support signaling, | |
1266 | perform server identity verification or prevent STARTTLS downgrade | |
1267 | attacks. The use of PKIX CAs offers no added security since an | |
22e6f294 JH |
1268 | attacker capable of compromising DNSSEC is free to replace any PKIX- |
1269 | TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient | |
1270 | non-PKIX certificate usage. | |
1271 | ||
1272 | SMTP servers SHOULD NOT publish TLSA RRs with certificate usage PKIX- | |
1273 | TA(0) or PKIX-EE(1). SMTP clients cannot be expected to be | |
1274 | configured with a suitably complete set of trusted public CAs. | |
1275 | Lacking a complete set of public CAs, clients would not be able to | |
1276 | verify the certificates of SMTP servers whose issuing root CAs are | |
1277 | not trusted by the client. | |
1278 | ||
1279 | Opportunistic DANE TLS needs to interoperate without bilateral | |
1280 | coordination of security settings between client and server systems. | |
1281 | Therefore, parameter choices that are fragile in the absence of | |
1282 | bilateral coordination are unsupported. Nothing is lost since the | |
1283 | PKIX certificate usages cannot aid SMTP TLS security, they can only | |
1284 | impede SMTP TLS interoperability. | |
1285 | ||
a46255cd JH |
1286 | |
1287 | ||
d8129d87 | 1288 | Dukhovni & Hardaker Expires February 18, 2015 [Page 23] |
a46255cd JH |
1289 | \f |
1290 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1291 | ||
1292 | ||
22e6f294 JH |
1293 | SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0) |
1294 | or PKIX-EE(1) is undefined. SMTP clients should generally treat such | |
1295 | TLSA records as unusable. | |
1296 | ||
1297 | 3.2. Certificate matching | |
1298 | ||
1299 | When at least one usable "secure" TLSA record is found, the SMTP | |
1300 | client MUST use TLSA records to authenticate the SMTP server. | |
1301 | Messages MUST NOT be delivered via the SMTP server if authentication | |
1302 | fails, otherwise the SMTP client is vulnerable to MITM attacks. | |
1303 | ||
1304 | 3.2.1. DANE-EE(3) name checks | |
1305 | ||
1306 | The SMTP client MUST NOT perform certificate name checks with | |
a46255cd | 1307 | certificate usage DANE-EE(3); see Section 3.1.1 above. |
22e6f294 JH |
1308 | |
1309 | 3.2.2. DANE-TA(2) name checks | |
1310 | ||
1311 | To match a server via a TLSA record with certificate usage DANE- | |
1312 | TA(2), the client MUST perform name checks to ensure that it has | |
1313 | reached the correct server. In all DANE-TA(2) cases the SMTP client | |
1314 | MUST include the TLSA base domain as one of the valid reference | |
1315 | identifiers for matching the server certificate. | |
1316 | ||
1317 | TLSA records for MX hostnames: If the TLSA base domain was obtained | |
1318 | indirectly via a "secure" MX lookup (including any CNAME-expanded | |
1319 | name of an MX hostname), then the original next-hop domain used in | |
1320 | the MX lookup MUST be included as as a second reference | |
1321 | identifier. The CNAME-expanded original next-hop domain MUST be | |
1322 | included as a third reference identifier if different from the | |
22e6f294 JH |
1323 | original next-hop domain. When the client MTA is employing DANE |
1324 | TLS security despite "insecure" MX redirection the MX hostname is | |
1325 | the only reference identifier. | |
1326 | ||
1327 | TLSA records for Non-MX hostnames: If MX records were not used | |
1328 | (e.g., if none exist) and the TLSA base domain is the CNAME- | |
1329 | expanded original next-hop domain, then the original next-hop | |
1330 | domain MUST be included as a second reference identifier. | |
1331 | ||
1332 | Accepting certificates with the original next-hop domain in addition | |
1333 | to the MX hostname allows a domain with multiple MX hostnames to | |
1334 | field a single certificate bearing a single domain name (i.e., the | |
1335 | email domain) across all the SMTP servers. This also aids | |
1336 | interoperability with pre-DANE SMTP clients that are configured to | |
1337 | look for the email domain name in server certificates. For example, | |
1338 | with "secure" DNS records as below: | |
1339 | ||
a46255cd JH |
1340 | |
1341 | ||
1342 | ||
1343 | ||
d8129d87 | 1344 | Dukhovni & Hardaker Expires February 18, 2015 [Page 24] |
a46255cd JH |
1345 | \f |
1346 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1347 | ||
1348 | ||
22e6f294 JH |
1349 | exchange.example.org. IN CNAME mail.example.org. |
1350 | mail.example.org. IN CNAME example.com. | |
1351 | example.com. IN MX 10 mx10.example.com. | |
1352 | example.com. IN MX 15 mx15.example.com. | |
1353 | example.com. IN MX 20 mx20.example.com. | |
1354 | ; | |
1355 | mx10.example.com. IN A 192.0.2.10 | |
1356 | _25._tcp.mx10.example.com. IN TLSA 2 0 1 ... | |
1357 | ; | |
1358 | mx15.example.com. IN CNAME mxbackup.example.com. | |
1359 | mxbackup.example.com. IN A 192.0.2.15 | |
1360 | ; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN) | |
1361 | _25._tcp.mx15.example.com. IN TLSA 2 0 1 ... | |
1362 | ; | |
1363 | mx20.example.com. IN CNAME mxbackup.example.net. | |
1364 | mxbackup.example.net. IN A 198.51.100.20 | |
1365 | _25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ... | |
1366 | ||
1367 | Certificate name checks for delivery of mail to exchange.example.org | |
1368 | via any of the associated SMTP servers MUST accept at least the names | |
1369 | "exchange.example.org" and "example.com", which are respectively the | |
1370 | original and fully expanded next-hop domain. When the SMTP server is | |
1371 | mx10.example.com, name checks MUST accept the TLSA base domain | |
1372 | "mx10.example.com". If, despite the fact that MX hostnames are | |
1373 | required to not be aliases, the MTA supports delivery via | |
1374 | "mx15.example.com" or "mx20.example.com" then name checks MUST accept | |
1375 | the respective TLSA base domains "mx15.example.com" and | |
1376 | "mxbackup.example.net". | |
1377 | ||
1378 | 3.2.3. Reference identifier matching | |
1379 | ||
22e6f294 JH |
1380 | When name checks are applicable (certificate usage DANE-TA(2)), if |
1381 | the server certificate contains a Subject Alternative Name extension | |
1382 | ([RFC5280]), with at least one DNS-ID ([RFC6125]) then only the DNS- | |
1383 | IDs are matched against the client's reference identifiers. The CN- | |
1384 | ID ([RFC6125]) is only considered when no DNS-IDs are present. The | |
1385 | server certificate is considered matched when one of its presented | |
1386 | identifiers ([RFC5280]) matches any of the client's reference | |
1387 | identifiers. | |
1388 | ||
1389 | Wildcards are valid in either DNS-IDs or the CN-ID when applicable. | |
1390 | The wildcard character must be entire first label of the DNS-ID or | |
1391 | CN-ID. Thus, "*.example.com" is valid, while "smtp*.example.com" and | |
1392 | "*smtp.example.com" are not. SMTP clients MUST support wildcards | |
1393 | that match the first label of the reference identifier, with the | |
1394 | remaining labels matching verbatim. For example, the DNS-ID | |
1395 | "*.example.com" matches the reference identifier "mx1.example.com". | |
1396 | SMTP clients MAY, subject to local policy allow wildcards to match | |
a46255cd JH |
1397 | |
1398 | ||
1399 | ||
d8129d87 | 1400 | Dukhovni & Hardaker Expires February 18, 2015 [Page 25] |
a46255cd JH |
1401 | \f |
1402 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1403 | ||
1404 | ||
22e6f294 JH |
1405 | multiple reference identifier labels, but servers cannot expect broad |
1406 | support for such a policy. Therefore any wildcards in server | |
1407 | certificates SHOULD match exactly one label in either the TLSA base | |
1408 | domain or the next-hop domain. | |
1409 | ||
1410 | 4. Server key management | |
1411 | ||
1412 | Two TLSA records MUST be published before employing a new EE or TA | |
1413 | public key or certificate, one matching the currently deployed key | |
1414 | and the other matching the new key scheduled to replace it. Once | |
1415 | sufficient time has elapsed for all DNS caches to expire the previous | |
1416 | TLSA RRset and related signature RRsets, servers may be configured to | |
1417 | use the new EE private key and associated public key certificate or | |
1418 | may employ certificates signed by the new trust anchor. | |
1419 | ||
1420 | Once the new public key or certificate is in use, the TLSA RR that | |
1421 | matches the retired key can be removed from DNS, leaving only RRs | |
1422 | that match keys or certificates in active use. | |
1423 | ||
1424 | As described in Section 3.1.2, when server certificates are validated | |
1425 | via a DANE-TA(2) trust anchor, and CNAME records are employed to | |
1426 | store the TA association data at a single location, the | |
1427 | responsibility of updating the TLSA RRset shifts to the operator of | |
1428 | the trust anchor. Before a new trust anchor is used to sign any new | |
1429 | server certificates, its certificate (digest) is added to the | |
1430 | relevant TLSA RRset. After enough time elapses for the original TLSA | |
1431 | RRset to age out of DNS caches, the new trust anchor can start | |
1432 | issuing new server certificates. Once all certificates issued under | |
1433 | the previous trust anchor have expired, its associated RRs can be | |
1434 | removed from the TLSA RRset. | |
1435 | ||
22e6f294 JH |
1436 | In the DANE-TA(2) key management model server operators do not |
1437 | generally need to update DNS TLSA records after initially creating a | |
1438 | CNAME record that references the centrally operated DANE-TA(2) RRset. | |
1439 | If a particular server's key is compromised, its TLSA CNAME SHOULD be | |
1440 | replaced with a DANE-EE(3) association until the certificate for the | |
d8129d87 JH |
1441 | compromised key expires, at which point it can return to using a |
1442 | CNAME record. If the central trust anchor is compromised, all | |
1443 | servers need to be issued new keys by a new TA, and an updated DANE- | |
1444 | TA(2) TLSA RRset needs to be published containing just the new TA. | |
1445 | ||
1446 | SMTP servers cannot expect broad CRL or OCSP support from SMTP | |
1447 | clients. As outlined above, with DANE, compromised server or trust | |
1448 | anchor keys can be "revoked" by removing them from the DNS without | |
1449 | the need for client-side support for OCSP or CRLs. | |
22e6f294 JH |
1450 | |
1451 | 5. Digest algorithm agility | |
1452 | ||
a46255cd JH |
1453 | |
1454 | ||
1455 | ||
d8129d87 | 1456 | Dukhovni & Hardaker Expires February 18, 2015 [Page 26] |
a46255cd JH |
1457 | \f |
1458 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1459 | ||
1460 | ||
d8129d87 JH |
1461 | While [RFC6698] specifies multiple digest algorithms, it does not |
1462 | specify a protocol by which the SMTP client and TLSA record publisher | |
1463 | can agree on the strongest shared algorithm. Such a protocol would | |
1464 | allow the client and server to avoid exposure to any deprecated | |
22e6f294 | 1465 | weaker algorithms that are published for compatibility with less |
d8129d87 JH |
1466 | capable clients, but should be ignored when possible. Such a |
1467 | protocol is specified in [I-D.ietf-dane-ops]. SMTP clients and | |
1468 | servers that implement this specification MUST comply with the | |
1469 | requirements outlined under "Digest Algorithm Agility" in | |
1470 | [I-D.ietf-dane-ops]. | |
22e6f294 JH |
1471 | |
1472 | 6. Mandatory TLS Security | |
1473 | ||
22e6f294 JH |
1474 | An MTA implementing this protocol may require a stronger security |
1475 | assurance when sending email to selected destinations. The sending | |
1476 | organization may need to send sensitive email and/or may have | |
1477 | regulatory obligations to protect its content. This protocol is not | |
1478 | in conflict with such a requirement, and in fact can often simplify | |
1479 | authenticated delivery to such destinations. | |
1480 | ||
1481 | Specifically, with domains that publish DANE TLSA records for their | |
1482 | MX hostnames, a sending MTA can be configured to use the receiving | |
1483 | domains's DANE TLSA records to authenticate the corresponding SMTP | |
1484 | server. Authentication via DANE TLSA records is easier to manage, as | |
1485 | changes in the receiver's expected certificate properties are made on | |
1486 | the receiver end and don't require manually communicated | |
1487 | configuration changes. With mandatory DANE TLS, when no usable TLSA | |
1488 | records are found, message delivery is delayed. Thus, mail is only | |
1489 | sent when an authenticated TLS channel is established to the remote | |
1490 | SMTP server. | |
1491 | ||
1492 | Administrators of mail servers that employ mandatory DANE TLS, need | |
1493 | to carefully monitor their mail logs and queues. If a partner domain | |
1494 | unwittingly misconfigures their TLSA records, disables DNSSEC, or | |
1495 | misconfigures SMTP server certificate chains, mail will be delayed | |
1496 | and may bounce if the issue is not resolved in a timely manner. | |
1497 | ||
1498 | 7. Note on DANE for Message User Agents | |
1499 | ||
1500 | We note that the SMTP protocol is also used between Message User | |
1501 | Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In | |
1502 | [RFC6186] a protocol is specified that enables an MUA to dynamically | |
1503 | locate the MSA based on the user's email address. SMTP connection | |
1504 | security considerations for MUAs implementing [RFC6186] are largely | |
1505 | analogous to connection security requirements for MTAs, and this | |
1506 | specification could be applied largely verbatim with DNS MX records | |
1507 | replaced by corresponding DNS Service (SRV) records | |
1508 | [I-D.ietf-dane-srv]. | |
1509 | ||
d8129d87 JH |
1510 | |
1511 | ||
1512 | Dukhovni & Hardaker Expires February 18, 2015 [Page 27] | |
1513 | \f | |
1514 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1515 | ||
1516 | ||
22e6f294 JH |
1517 | However, until MUAs begin to adopt the dynamic configuration |
1518 | mechanisms of [RFC6186] they are adequately served by more | |
1519 | traditional static TLS security policies. Specification of DANE TLS | |
1520 | for Message User Agent (MUA) to Message Submission Agent (MSA) SMTP | |
1521 | is left to future documents that focus specifically on SMTP security | |
1522 | between MUAs and MSAs. | |
1523 | ||
22e6f294 JH |
1524 | 8. Interoperability considerations |
1525 | ||
1526 | 8.1. SNI support | |
1527 | ||
1528 | To ensure that the server sends the right certificate chain, the SMTP | |
1529 | client MUST send the TLS SNI extension containing the TLSA base | |
1530 | domain. This precludes the use of the backward compatible SSL 2.0 | |
1531 | compatible SSL HELLO by the SMTP client. The minimum SSL/TLS client | |
1532 | HELLO version for SMTP clients performing DANE authentication is SSL | |
1533 | 3.0, but a client that offers SSL 3.0 MUST also offer at least TLS | |
1534 | 1.0 and MUST include the SNI extension. Servers that don't make use | |
1535 | of SNI MAY negotiate SSL 3.0 if offered by the client. | |
1536 | ||
1537 | Each SMTP server MUST present a certificate chain (see [RFC5246] | |
1538 | Section 7.4.2) that matches at least one of the TLSA records. The | |
1539 | server MAY rely on SNI to determine which certificate chain to | |
1540 | present to the client. Clients that don't send SNI information may | |
1541 | not see the expected certificate chain. | |
1542 | ||
1543 | If the server's TLSA records match the server's default certificate | |
1544 | chain, the server need not support SNI. In either case, the server | |
1545 | need not include the SNI extension in its TLS HELLO as simply | |
1546 | returning a matching certificate chain is sufficient. Servers MUST | |
1547 | NOT enforce the use of SNI by clients, as the client may be using | |
1548 | unauthenticated opportunistic TLS and may not expect any particular | |
1549 | certificate from the server. If the client sends no SNI extension, | |
1550 | or sends an SNI extension for an unsupported domain, the server MUST | |
1551 | simply send some fallback certificate chain of its choice. The | |
1552 | reason for not enforcing strict matching of the requested SNI | |
1553 | hostname is that DANE TLS clients are typically willing to accept | |
1554 | multiple server names, but can only send one name in the SNI | |
1555 | extension. The server's fallback certificate may match a different | |
1556 | name acceptable to the client, e.g., the original next-hop domain. | |
1557 | ||
1558 | 8.2. Anonymous TLS cipher suites | |
1559 | ||
1560 | Since many SMTP servers either do not support or do not enable any | |
1561 | anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD | |
1562 | offer to negotiate a typical set of non-anonymous cipher suites | |
1563 | required for interoperability with such servers. An SMTP client | |
1564 | employing pre-DANE opportunistic TLS MAY in addition include one or | |
d8129d87 JH |
1565 | |
1566 | ||
1567 | ||
1568 | Dukhovni & Hardaker Expires February 18, 2015 [Page 28] | |
1569 | \f | |
1570 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1571 | ||
1572 | ||
22e6f294 JH |
1573 | more anonymous TLS cipher suites in its TLS HELLO. SMTP servers, |
1574 | that need to interoperate with opportunistic TLS clients SHOULD be | |
1575 | prepared to interoperate with such clients by either always selecting | |
1576 | a mutually supported non-anonymous cipher suite or by correctly | |
1577 | handling client connections that negotiate anonymous cipher suites. | |
1578 | ||
22e6f294 JH |
1579 | Note that while SMTP server operators are under no obligation to |
1580 | enable anonymous cipher suites, no security is gained by sending | |
1581 | certificates to clients that will ignore them. Indeed support for | |
1582 | anonymous cipher suites in the server makes audit trails more | |
1583 | informative. Log entries that record connections that employed an | |
1584 | anonymous cipher suite record the fact that the clients did not care | |
1585 | to authenticate the server. | |
1586 | ||
1587 | 9. Operational Considerations | |
1588 | ||
1589 | 9.1. Client Operational Considerations | |
1590 | ||
1591 | An operational error on the sending or receiving side that cannot be | |
1592 | corrected in a timely manner may, at times, lead to consistent | |
1593 | failure to deliver time-sensitive email. The sending MTA | |
1594 | administrator may have to choose between letting email queue until | |
1595 | the error is resolved and disabling opportunistic or mandatory DANE | |
1596 | TLS for one or more destinations. The choice to disable DANE TLS | |
1597 | security should not be made lightly. Every reasonable effort should | |
1598 | be made to determine that problems with mail delivery are the result | |
1599 | of an operational error, and not an attack. A fallback strategy may | |
1600 | be to configure explicit out-of-band TLS security settings if | |
1601 | supported by the sending MTA. | |
1602 | ||
1603 | SMTP clients may deploy opportunistic DANE TLS incrementally by | |
1604 | enabling it only for selected sites, or may occasionally need to | |
1605 | disable opportunistic DANE TLS for peers that fail to interoperate | |
1606 | due to misconfiguration or software defects on either end. Some | |
1607 | implementations MAY support DANE TLS in an "audit only" mode in which | |
1608 | failure to achieve the requisite security level is logged as a | |
1609 | warning and delivery proceeds at a reduced security level. Unless | |
1610 | local policy specifies "audit only" or that opportunistic DANE TLS is | |
1611 | not to be used for a particular destination, an SMTP client MUST NOT | |
1612 | deliver mail via a server whose certificate chain fails to match at | |
1613 | least one TLSA record when usable TLSA records are found for that | |
1614 | server. | |
1615 | ||
d8129d87 JH |
1616 | |
1617 | ||
1618 | ||
1619 | ||
1620 | ||
1621 | ||
1622 | ||
1623 | ||
1624 | Dukhovni & Hardaker Expires February 18, 2015 [Page 29] | |
1625 | \f | |
1626 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1627 | ||
1628 | ||
22e6f294 JH |
1629 | 9.2. Publisher Operational Considerations |
1630 | ||
1631 | SMTP servers that publish certificate usage DANE-TA(2) associations | |
1632 | MUST include the TA certificate in their TLS server certificate | |
1633 | chain, even when that TA certificate is a self-signed root | |
1634 | certificate. | |
1635 | ||
d8129d87 JH |
1636 | TLSA Publishers MUST follow the guidelines in the "TLSA Publisher |
1637 | Requirements" section of [I-D.ietf-dane-ops]. | |
22e6f294 | 1638 | |
d8129d87 JH |
1639 | TLSA Publishers SHOULD follow the TLSA publication size guidance |
1640 | found in [I-D.ietf-dane-ops] under "DANE DNS Record Size Guidelines". | |
22e6f294 JH |
1641 | |
1642 | 10. Security Considerations | |
1643 | ||
1644 | This protocol leverages DANE TLSA records to implement MITM resistant | |
a46255cd JH |
1645 | opportunistic security ([I-D.dukhovni-opportunistic-security]) for |
1646 | SMTP. For destination domains that sign their MX records and publish | |
1647 | signed TLSA records for their MX hostnames, this protocol allows | |
1648 | sending MTAs to securely discover both the availability of TLS and | |
1649 | how to authenticate the destination. | |
1650 | ||
22e6f294 JH |
1651 | This protocol does not aim to secure all SMTP traffic, as that is not |
1652 | practical until DNSSEC and DANE adoption are universal. The | |
1653 | incremental deployment provided by following this specification is a | |
1654 | best possible path for securing SMTP. This protocol coexists and | |
1655 | interoperates with the existing insecure Internet email backbone. | |
1656 | ||
1657 | The protocol does not preclude existing non-opportunistic SMTP TLS | |
1658 | security arrangements, which can continue to be used as before via | |
1659 | manual configuration with negotiated out-of-band key and TLS | |
1660 | configuration exchanges. | |
1661 | ||
1662 | Opportunistic SMTP TLS depends critically on DNSSEC for downgrade | |
1663 | resistance and secure resolution of the destination name. If DNSSEC | |
1664 | is compromised, it is not possible to fall back on the public CA PKI | |
1665 | to prevent MITM attacks. A successful breach of DNSSEC enables the | |
1666 | attacker to publish TLSA usage 3 certificate associations, and | |
1667 | thereby bypass any security benefit the legitimate domain owner might | |
1668 | hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of | |
1669 | public CA PKI support in existing MTA deployments, avoiding | |
1670 | certificate usages 0 and 1 simplifies implementation and deployment | |
1671 | with no adverse security consequences. | |
1672 | ||
1673 | Implementations must strictly follow the portions of this | |
1674 | specification that indicate when it is appropriate to initiate a non- | |
1675 | authenticated connection or cleartext connection to a SMTP server. | |
1676 | Specifically, in order to prevent downgrade attacks on this protocol, | |
d8129d87 JH |
1677 | |
1678 | ||
1679 | ||
1680 | Dukhovni & Hardaker Expires February 18, 2015 [Page 30] | |
1681 | \f | |
1682 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1683 | ||
1684 | ||
22e6f294 JH |
1685 | implementation must not initiate a connection when this specification |
1686 | indicates a particular SMTP server must be considered unreachable. | |
1687 | ||
1688 | 11. IANA considerations | |
1689 | ||
1690 | This specification requires no support from IANA. | |
1691 | ||
1692 | 12. Acknowledgements | |
1693 | ||
1694 | The authors would like to extend great thanks to Tony Finch, who | |
1695 | started the original version of a DANE SMTP document. His work is | |
22e6f294 JH |
1696 | greatly appreciated and has been incorporated into this document. |
1697 | The authors would like to additionally thank Phil Pennock for his | |
1698 | comments and advice on this document. | |
1699 | ||
1700 | Acknowledgments from Viktor: Thanks to Paul Hoffman who motivated me | |
1701 | to begin work on this memo and provided feedback on early drafts. | |
1702 | Thanks to Patrick Koetter, Perry Metzger and Nico Williams for | |
1703 | valuable review comments. Thanks also to Wietse Venema who created | |
1704 | Postfix, and whose advice and feedback were essential to the | |
1705 | development of the Postfix DANE implementation. | |
1706 | ||
1707 | 13. References | |
1708 | ||
1709 | 13.1. Normative References | |
1710 | ||
1711 | [I-D.ietf-dane-ops] | |
d8129d87 JH |
1712 | Dukhovni, V. and W. Hardaker, "Updates to and Operational |
1713 | Guidance for the DANE Protocol", draft-ietf-dane-ops-06 | |
1714 | (work in progress), August 2014. | |
22e6f294 JH |
1715 | |
1716 | [RFC1035] Mockapetris, P., "Domain names - implementation and | |
1717 | specification", STD 13, RFC 1035, November 1987. | |
1718 | ||
1719 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |
1720 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
1721 | ||
1722 | [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over | |
1723 | Transport Layer Security", RFC 3207, February 2002. | |
1724 | ||
1725 | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |
1726 | Rose, "DNS Security Introduction and Requirements", RFC | |
1727 | 4033, March 2005. | |
1728 | ||
1729 | [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |
1730 | Rose, "Resource Records for the DNS Security Extensions", | |
1731 | RFC 4034, March 2005. | |
1732 | ||
d8129d87 JH |
1733 | |
1734 | ||
1735 | ||
1736 | Dukhovni & Hardaker Expires February 18, 2015 [Page 31] | |
1737 | \f | |
1738 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
1739 | ||
1740 | ||
22e6f294 JH |
1741 | [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
1742 | Rose, "Protocol Modifications for the DNS Security | |
1743 | Extensions", RFC 4035, March 2005. | |
1744 | ||
1745 | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |
1746 | (TLS) Protocol Version 1.2", RFC 5246, August 2008. | |
1747 | ||
1748 | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |
1749 | Housley, R., and W. Polk, "Internet X.509 Public Key | |
1750 | Infrastructure Certificate and Certificate Revocation List | |
1751 | (CRL) Profile", RFC 5280, May 2008. | |
1752 | ||
22e6f294 JH |
1753 | [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, |
1754 | October 2008. | |
1755 | ||
1756 | [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: | |
1757 | Extension Definitions", RFC 6066, January 2011. | |
1758 | ||
1759 | [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | |
1760 | Verification of Domain-Based Application Service Identity | |
1761 | within Internet Public Key Infrastructure Using X.509 | |
1762 | (PKIX) Certificates in the Context of Transport Layer | |
1763 | Security (TLS)", RFC 6125, March 2011. | |
1764 | ||
1765 | [RFC6186] Daboo, C., "Use of SRV Records for Locating Email | |
1766 | Submission/Access Services", RFC 6186, March 2011. | |
1767 | ||
1768 | [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the | |
1769 | DNS", RFC 6672, June 2012. | |
1770 | ||
1771 | [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication | |
1772 | of Named Entities (DANE) Transport Layer Security (TLS) | |
1773 | Protocol: TLSA", RFC 6698, August 2012. | |
1774 | ||
a46255cd JH |
1775 | [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify |
1776 | Conversations about DNS-Based Authentication of Named | |
1777 | Entities (DANE)", RFC 7218, April 2014. | |
1778 | ||
1779 | [X.690] International Telecommunications Union, "Recommendation | |
1780 | ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information | |
1781 | technology - ASN.1 encoding rules: Specification of Basic | |
1782 | Encoding Rules (BER), Canonical Encoding Rules (CER) and | |
1783 | Distinguished Encoding Rules (DER)", July 2002. | |
1784 | ||
22e6f294 JH |
1785 | 13.2. Informative References |
1786 | ||
a46255cd | 1787 | [I-D.dukhovni-opportunistic-security] |
22e6f294 | 1788 | |
22e6f294 | 1789 | |
22e6f294 | 1790 | |
22e6f294 | 1791 | |
d8129d87 JH |
1792 | Dukhovni & Hardaker Expires February 18, 2015 [Page 32] |
1793 | \f | |
1794 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 | |
22e6f294 | 1795 | |
22e6f294 | 1796 | |
d8129d87 JH |
1797 | Dukhovni, V., "Opportunistic Security: Some Protection |
1798 | Most of the Time", draft-dukhovni-opportunistic- | |
1799 | security-03 (work in progress), August 2014. | |
22e6f294 | 1800 | |
d8129d87 JH |
1801 | [I-D.ietf-dane-srv] |
1802 | Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- | |
1803 | Based Authentication of Named Entities (DANE) TLSA Records | |
1804 | with SRV Records", draft-ietf-dane-srv-07 (work in | |
1805 | progress), July 2014. | |
22e6f294 | 1806 | |
d8129d87 JH |
1807 | [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July |
1808 | 2009. | |
22e6f294 | 1809 | |
d8129d87 JH |
1810 | [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", |
1811 | STD 72, RFC 6409, November 2011. | |
a46255cd | 1812 | |
d8129d87 | 1813 | Authors' Addresses |
a46255cd JH |
1814 | |
1815 | Viktor Dukhovni | |
1816 | Two Sigma | |
1817 | ||
1818 | Email: ietf-dane@dukhovni.org | |
22e6f294 JH |
1819 | |
1820 | ||
1821 | Wes Hardaker | |
1822 | Parsons | |
1823 | P.O. Box 382 | |
1824 | Davis, CA 95617 | |
1825 | US | |
1826 | ||
1827 | Email: ietf@hardakers.net | |
1828 | ||
1829 | ||
1830 | ||
1831 | ||
1832 | ||
1833 | ||
1834 | ||
1835 | ||
1836 | ||
1837 | ||
1838 | ||
1839 | ||
1840 | ||
1841 | ||
1842 | ||
1843 | ||
1844 | ||
1845 | ||
1846 | ||
1847 | ||
d8129d87 | 1848 | Dukhovni & Hardaker Expires February 18, 2015 [Page 33] |