| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | DANE V. Dukhovni |
| 6 | Internet-Draft Two Sigma |
| 7 | Intended status: Standards Track W. Hardaker |
| 8 | Expires: February 18, 2015 Parsons |
| 9 | August 17, 2014 |
| 10 | |
| 11 | |
| 12 | SMTP security via opportunistic DANE TLS |
| 13 | draft-ietf-dane-smtp-with-dane-12 |
| 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 | |
| 39 | This Internet-Draft will expire on February 18, 2015. |
| 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 | |
| 56 | Dukhovni & Hardaker Expires February 18, 2015 [Page 1] |
| 57 | \f |
| 58 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 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 |
| 72 | 1.3.3. Sender policy does not scale . . . . . . . . . . . . 8 |
| 73 | 1.3.4. Too many certification authorities . . . . . . . . . 8 |
| 74 | 2. Identifying applicable TLSA records . . . . . . . . . . . . . 9 |
| 75 | 2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 9 |
| 76 | 2.1.1. DNS errors, bogus and indeterminate responses . . . . 9 |
| 77 | 2.1.2. DNS error handling . . . . . . . . . . . . . . . . . 11 |
| 78 | 2.1.3. Stub resolver considerations . . . . . . . . . . . . 12 |
| 79 | 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 13 |
| 80 | 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 14 |
| 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 |
| 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 |
| 93 | 5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26 |
| 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] |
| 113 | \f |
| 114 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 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 |
| 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. |
| 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 | |
| 168 | Dukhovni & Hardaker Expires February 18, 2015 [Page 3] |
| 169 | \f |
| 170 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 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 |
| 180 | Stub Resolver. |
| 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 | |
| 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 | |
| 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 |
| 215 | deliverable later the message is queued and delivery is retried |
| 216 | periodically. Some MTAs may be configured with a fallback next- |
| 217 | hop destination that handles messages that the MTA would otherwise |
| 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 |
| 221 | |
| 222 | |
| 223 | |
| 224 | Dukhovni & Hardaker Expires February 18, 2015 [Page 4] |
| 225 | \f |
| 226 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 227 | |
| 228 | |
| 229 | may itself be subject to opportunistic or mandatory DANE TLS as |
| 230 | though it were the original message destination. |
| 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 | |
| 280 | Dukhovni & Hardaker Expires February 18, 2015 [Page 5] |
| 281 | \f |
| 282 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 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 |
| 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 | |
| 336 | Dukhovni & Hardaker Expires February 18, 2015 [Page 6] |
| 337 | \f |
| 338 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 339 | |
| 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 | |
| 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 |
| 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. |
| 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 | |
| 390 | |
| 391 | |
| 392 | Dukhovni & Hardaker Expires February 18, 2015 [Page 7] |
| 393 | \f |
| 394 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 395 | |
| 396 | |
| 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 |
| 402 | selected high-value receiving domains by configuring explicit trust |
| 403 | anchors for those domains instead of relying on the chain of trust |
| 404 | from the root domain. However, detailed discussion of DNSSEC |
| 405 | security practices is out of scope for this document. |
| 406 | |
| 407 | 1.3.3. Sender policy does not scale |
| 408 | |
| 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 |
| 436 | fails. With no user to "click OK", the MTA's list of public CA trust |
| 437 | anchors would need to be comprehensive in order to avoid bouncing |
| 438 | mail addressed to sites that employ unknown Certification |
| 439 | Authorities. |
| 440 | |
| 441 | |
| 442 | |
| 443 | |
| 444 | |
| 445 | |
| 446 | |
| 447 | |
| 448 | Dukhovni & Hardaker Expires February 18, 2015 [Page 8] |
| 449 | \f |
| 450 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 451 | |
| 452 | |
| 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. |
| 458 | |
| 459 | 2. Identifying applicable TLSA records |
| 460 | |
| 461 | 2.1. DNS considerations |
| 462 | |
| 463 | 2.1.1. DNS errors, bogus and indeterminate responses |
| 464 | |
| 465 | An SMTP client that implements opportunistic DANE TLS per this |
| 466 | specification depends critically on the integrity of DNSSEC lookups, |
| 467 | as discussed in Section 1.3.2. This section lists the DNS resolver |
| 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 | |
| 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 | |
| 495 | SMTP clients following this specification SHOULD NOT distinguish |
| 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 |
| 500 | follows, the term "insecure" will also include the case of |
| 501 | |
| 502 | |
| 503 | |
| 504 | Dukhovni & Hardaker Expires February 18, 2015 [Page 9] |
| 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. |
| 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 |
| 519 | "indeterminate" security status (in the sense of RFC4035) to the |
| 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 | |
| 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 |
| 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]: |
| 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 | |
| 556 | |
| 557 | |
| 558 | |
| 559 | |
| 560 | Dukhovni & Hardaker Expires February 18, 2015 [Page 10] |
| 561 | \f |
| 562 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 563 | |
| 564 | |
| 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 | |
| 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 | |
| 612 | |
| 613 | |
| 614 | |
| 615 | |
| 616 | Dukhovni & Hardaker Expires February 18, 2015 [Page 11] |
| 617 | \f |
| 618 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 619 | |
| 620 | |
| 621 | 2.1.3. Stub resolver considerations |
| 622 | |
| 623 | SMTP clients that employ opportunistic DANE TLS to secure connections |
| 624 | to SMTP servers MUST NOT use Security-Oblivious stub-resolvers. |
| 625 | |
| 626 | A note about DNAME aliases: a query for a domain name whose ancestor |
| 627 | domain is a DNAME alias returns the DNAME RR for the ancestor domain |
| 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 |
| 633 | DNAME records is needed in SMTP software; it is sufficient to process |
| 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 |
| 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 | |
| 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". |
| 664 | |
| 665 | If the SMTP client needs to determine the security status of the DNS |
| 666 | zone containing the initial CNAME record, it may need to issue a |
| 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 |
| 669 | |
| 670 | |
| 671 | |
| 672 | Dukhovni & Hardaker Expires February 18, 2015 [Page 12] |
| 673 | \f |
| 674 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 675 | |
| 676 | |
| 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 | |
| 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 | |
| 705 | A secure non-empty TLSA RRset where all the records are unusable: A |
| 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 |
| 725 | |
| 726 | |
| 727 | |
| 728 | Dukhovni & Hardaker Expires February 18, 2015 [Page 13] |
| 729 | \f |
| 730 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 731 | |
| 732 | |
| 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 |
| 741 | lieu of an MX hostname, if an MTA chooses to connect to the network |
| 742 | address in the non-conformant MX record, DANE TLSA does not apply for |
| 743 | such a connection. |
| 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 |
| 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 |
| 775 | is performed repeatedly (up to the MTA's recursion limit) until the |
| 776 | ultimate non-CNAME domain is found. |
| 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 |
| 781 | |
| 782 | |
| 783 | |
| 784 | Dukhovni & Hardaker Expires February 18, 2015 [Page 14] |
| 785 | \f |
| 786 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 787 | |
| 788 | |
| 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 | |
| 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 | |
| 838 | |
| 839 | |
| 840 | Dukhovni & Hardaker Expires February 18, 2015 [Page 15] |
| 841 | \f |
| 842 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 843 | |
| 844 | |
| 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 |
| 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 |
| 878 | performed recursively (up to the MTA's recursion limit). |
| 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 | |
| 887 | |
| 888 | |
| 889 | |
| 890 | |
| 891 | |
| 892 | |
| 893 | |
| 894 | |
| 895 | |
| 896 | Dukhovni & Hardaker Expires February 18, 2015 [Page 16] |
| 897 | \f |
| 898 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 899 | |
| 900 | |
| 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 | |
| 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 | |
| 948 | |
| 949 | |
| 950 | |
| 951 | |
| 952 | Dukhovni & Hardaker Expires February 18, 2015 [Page 17] |
| 953 | \f |
| 954 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 955 | |
| 956 | |
| 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 |
| 963 | base domain is tried instead. |
| 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 |
| 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 | |
| 985 | Note that shared end entity certificate associations expose the |
| 986 | publishing domain to substitution attacks, where an MITM attacker can |
| 987 | reroute traffic to a different server that shares the same end entity |
| 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). |
| 992 | |
| 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: |
| 996 | |
| 997 | example.com. IN MX 0 mx1.example.com. |
| 998 | example.com. IN MX 0 mx2.example.com. |
| 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... |
| 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 |
| 1005 | |
| 1006 | |
| 1007 | |
| 1008 | Dukhovni & Hardaker Expires February 18, 2015 [Page 18] |
| 1009 | \f |
| 1010 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 1011 | |
| 1012 | |
| 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 | |
| 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 |
| 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 | |
| 1064 | Dukhovni & Hardaker Expires February 18, 2015 [Page 19] |
| 1065 | \f |
| 1066 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 1067 | |
| 1068 | |
| 1069 | The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698] |
| 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. |
| 1074 | |
| 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: |
| 1077 | PrivSel(255). All other values are reserved for use by future |
| 1078 | specifications. |
| 1079 | |
| 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. |
| 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 |
| 1092 | subjectPublicKeyInfo is an ASN.1 DER ([X.690]) encoding of the |
| 1093 | certificate's algorithm id, any parameters and the public key data. |
| 1094 | |
| 1095 | The matching type field specifies how the TLSA RR Certificate |
| 1096 | Association Data field is to be compared with the certificate or |
| 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 | |
| 1111 | |
| 1112 | |
| 1113 | |
| 1114 | |
| 1115 | |
| 1116 | |
| 1117 | |
| 1118 | |
| 1119 | |
| 1120 | Dukhovni & Hardaker Expires February 18, 2015 [Page 20] |
| 1121 | \f |
| 1122 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 1123 | |
| 1124 | |
| 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 | |
| 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 | |
| 1172 | |
| 1173 | |
| 1174 | |
| 1175 | |
| 1176 | Dukhovni & Hardaker Expires February 18, 2015 [Page 21] |
| 1177 | \f |
| 1178 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 1179 | |
| 1180 | |
| 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. |
| 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.... |
| 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 | |
| 1230 | |
| 1231 | |
| 1232 | Dukhovni & Hardaker Expires February 18, 2015 [Page 22] |
| 1233 | \f |
| 1234 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 1235 | |
| 1236 | |
| 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 |
| 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 | |
| 1286 | |
| 1287 | |
| 1288 | Dukhovni & Hardaker Expires February 18, 2015 [Page 23] |
| 1289 | \f |
| 1290 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 1291 | |
| 1292 | |
| 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 |
| 1307 | certificate usage DANE-EE(3); see Section 3.1.1 above. |
| 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 |
| 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 | |
| 1340 | |
| 1341 | |
| 1342 | |
| 1343 | |
| 1344 | Dukhovni & Hardaker Expires February 18, 2015 [Page 24] |
| 1345 | \f |
| 1346 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 1347 | |
| 1348 | |
| 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 | |
| 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 |
| 1397 | |
| 1398 | |
| 1399 | |
| 1400 | Dukhovni & Hardaker Expires February 18, 2015 [Page 25] |
| 1401 | \f |
| 1402 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 1403 | |
| 1404 | |
| 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 | |
| 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 |
| 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. |
| 1450 | |
| 1451 | 5. Digest algorithm agility |
| 1452 | |
| 1453 | |
| 1454 | |
| 1455 | |
| 1456 | Dukhovni & Hardaker Expires February 18, 2015 [Page 26] |
| 1457 | \f |
| 1458 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 1459 | |
| 1460 | |
| 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 |
| 1465 | weaker algorithms that are published for compatibility with less |
| 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]. |
| 1471 | |
| 1472 | 6. Mandatory TLS Security |
| 1473 | |
| 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 | |
| 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 | |
| 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 | |
| 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 |
| 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 | |
| 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 | |
| 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 | |
| 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 | |
| 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 | |
| 1636 | TLSA Publishers MUST follow the guidelines in the "TLSA Publisher |
| 1637 | Requirements" section of [I-D.ietf-dane-ops]. |
| 1638 | |
| 1639 | TLSA Publishers SHOULD follow the TLSA publication size guidance |
| 1640 | found in [I-D.ietf-dane-ops] under "DANE DNS Record Size Guidelines". |
| 1641 | |
| 1642 | 10. Security Considerations |
| 1643 | |
| 1644 | This protocol leverages DANE TLSA records to implement MITM resistant |
| 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 | |
| 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, |
| 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 | |
| 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 |
| 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] |
| 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. |
| 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 | |
| 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 | |
| 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 | |
| 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 | |
| 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 | |
| 1785 | 13.2. Informative References |
| 1786 | |
| 1787 | [I-D.dukhovni-opportunistic-security] |
| 1788 | |
| 1789 | |
| 1790 | |
| 1791 | |
| 1792 | Dukhovni & Hardaker Expires February 18, 2015 [Page 32] |
| 1793 | \f |
| 1794 | Internet-Draft SMTP security via opportunistic DANE TLS August 2014 |
| 1795 | |
| 1796 | |
| 1797 | Dukhovni, V., "Opportunistic Security: Some Protection |
| 1798 | Most of the Time", draft-dukhovni-opportunistic- |
| 1799 | security-03 (work in progress), August 2014. |
| 1800 | |
| 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. |
| 1806 | |
| 1807 | [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July |
| 1808 | 2009. |
| 1809 | |
| 1810 | [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", |
| 1811 | STD 72, RFC 6409, November 2011. |
| 1812 | |
| 1813 | Authors' Addresses |
| 1814 | |
| 1815 | Viktor Dukhovni |
| 1816 | Two Sigma |
| 1817 | |
| 1818 | Email: ietf-dane@dukhovni.org |
| 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 | |
| 1848 | Dukhovni & Hardaker Expires February 18, 2015 [Page 33] |