diff options
| -rw-r--r-- | doc/doc-txt/draft-ietf-dane-smtp-with-dane-10.txt | 1904 |
1 files changed, 1904 insertions, 0 deletions
diff --git a/doc/doc-txt/draft-ietf-dane-smtp-with-dane-10.txt b/doc/doc-txt/draft-ietf-dane-smtp-with-dane-10.txt new file mode 100644 index 000000000..99d17e88e --- /dev/null +++ b/doc/doc-txt/draft-ietf-dane-smtp-with-dane-10.txt @@ -0,0 +1,1904 @@ + + + + +DANE V. Dukhovni +Internet-Draft Two Sigma +Intended status: Standards Track W. Hardaker +Expires: November 26, 2014 Parsons + May 25, 2014 + + + SMTP security via opportunistic DANE TLS + draft-ietf-dane-smtp-with-dane-10 + +Abstract + + This memo describes a downgrade-resistant protocol for SMTP transport + security between Mail Transfer Agents (MTAs) based on the DNS-Based + Authentication of Named Entities (DANE) TLSA DNS record. Adoption of + this protocol enables an incremental transition of the Internet email + backbone to one using encrypted and authenticated Transport Layer + Security (TLS). + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on November 26, 2014. + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 1] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 6 + 1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 6 + 1.3.2. Insecure server name without DNSSEC . . . . . . . . . 7 + 1.3.3. Sender policy does not scale . . . . . . . . . . . . 7 + 1.3.4. Too many certification authorities . . . . . . . . . 8 + 2. Identifying applicable TLSA records . . . . . . . . . . . . . 8 + 2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 8 + 2.1.1. DNS errors, bogus and indeterminate responses . . . . 8 + 2.1.2. DNS error handling . . . . . . . . . . . . . . . . . 11 + 2.1.3. Stub resolver considerations . . . . . . . . . . . . 11 + 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 12 + 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 13 + 2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 15 + 2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 17 + 3. DANE authentication . . . . . . . . . . . . . . . . . . . . . 19 + 3.1. TLSA certificate usages . . . . . . . . . . . . . . . . . 19 + 3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 20 + 3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 21 + 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 22 + 3.2. Certificate matching . . . . . . . . . . . . . . . . . . 23 + 3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 23 + 3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 23 + 3.2.3. Reference identifier matching . . . . . . . . . . . . 24 + 4. Server key management . . . . . . . . . . . . . . . . . . . . 25 + 5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26 + 6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 27 + 7. Note on DANE for Message User Agents . . . . . . . . . . . . 28 + 8. Interoperability considerations . . . . . . . . . . . . . . . 29 + 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 29 + 9. Operational Considerations . . . . . . . . . . . . . . . . . 30 + 9.1. Client Operational Considerations . . . . . . . . . . . . 30 + 9.2. Publisher Operational Considerations . . . . . . . . . . 30 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 + 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 32 + 13.2. Informative References . . . . . . . . . . . . . . . . . 33 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 2] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + +1. Introduction + + This memo specifies a new connection security model for Message + Transfer Agents (MTAs). This model is motivated by key features of + inter-domain SMTP delivery, in particular the fact that the + destination server is selected indirectly via DNS Mail Exchange (MX) + records and that neither email addresses nor MX hostnames signal a + requirement for either secure or cleartext transport. Therefore, + aside from a few manually configured exceptions, SMTP transport + security is of necessity opportunistic. + + This specification uses the presence of DANE TLSA records to securely + signal TLS support and to publish the means by which SMTP clients can + successfully authenticate legitimate SMTP servers. This becomes + "opportunistic DANE TLS" and is resistant to downgrade and MITM + attacks. It enables an incremental transition of the email backbone + to authenticated TLS delivery, with increased global protection as + adoption increases. + + With opportunistic DANE TLS, traffic from SMTP clients to domains + that publish "usable" DANE TLSA records in accordance with this memo + is authenticated and encrypted. Traffic from legacy clients or to + domains that do not publish TLSA records will continue to be sent in + the same manner as before, via manually configured security, (pre- + DANE) opportunistic TLS or just cleartext SMTP. + + Problems with existing use of TLS in MTA to MTA SMTP that motivate + this specification are described in Section 1.3. The specification + itself follows in Section 2 and Section 3 which describe respectively + how to locate and use DANE TLSA records with SMTP. In Section 6, we + discuss application of DANE TLS to destinations for which channel + integrity and confidentiality are mandatory. In Section 7 we briefly + comment on potential applicability of this specification to Message + User Agents. + +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + The following terms or concepts are used through the document: + + Man-in-the-middle or MITM attack: Active modification of network + traffic by an adversary able to thereby compromise the + confidentiality or integrity of the data. + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 3] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + secure, bogus, insecure, indeterminate: DNSSEC validation results, + as defined in Section 4.3 of [RFC4035]. + + Validating Security-Aware Stub Resolver and Non-Validating + Security-Aware Stub Resolver: + Capabilities of the stub resolver in use as defined in [RFC4033]; + note that this specification requires the use of a Security-Aware + Stub Resolver; Security-Oblivious stub-resolvers MUST NOT be used. + + opportunistic DANE TLS: Best-effort use of TLS, resistant to + downgrade attacks for destinations with DNSSEC-validated TLSA + records. When opportunistic DANE TLS is determined to be + unavailable, clients should fall back to opportunistic TLS below. + Opportunistic DANE TLS requires support for DNSSEC, DANE and + STARTTLS on the client side and STARTTLS plus a DNSSEC published + TLSA record on the server side. + + (pre-DANE) opportunistic TLS: Best-effort use of TLS that is + generally vulnerable to DNS forgery and STARTTLS downgrade + attacks. When a TLS-encrypted communication channel is not + available, message transmission takes place in the clear. MX + record indirection generally precludes authentication even when + TLS is available. + + reference identifier: (Special case of [RFC6125] definition). One + of the domain names associated by the SMTP client with the + destination SMTP server for performing name checks on the server + certificate. When name checks are applicable, at least one of the + reference identifiers MUST match an [RFC6125] DNS-ID (or if none + are present the [RFC6125] CN-ID) of the server certificate (see + Section 3.2.3). + + MX hostname: The RRDATA of an MX record consists of a 16 bit + preference followed by a Mail Exchange domain name (see [RFC1035], + Section 3.3.9). We will use the term "MX hostname" to refer to + the latter, that is, the DNS domain name found after the + preference value in an MX record. Thus an "MX hostname" is + specifically a reference to a DNS domain name, rather than any + host that bears that name. + + delayed delivery: Email delivery is a multi-hop store & forward + process. When an MTA is unable forward a message that may become + deliverable later, the message is queued and delivery is retried + periodically. Some MTAs may be configured with a fallback next- + hop destination that handles messages that the MTA would otherwise + queue and retry. In these cases, messages that would otherwise + have to be delayed, may be sent to the fallback next-hop + destination instead. The fallback destination may itself be + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 4] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + subject to opportunistic or mandatory DANE TLS as though it were + the original message destination. + + original next hop destination: The logical destination for mail + delivery. By default this is the domain portion of the recipient + address, but MTAs may be configured to forward mail for some or + all recipients via designated relays. The original next hop + destination is, respectively, either the recipient domain or the + associated configured relay. + + MTA: Message Transfer Agent ([RFC5598], Section 4.3.2). + + MSA: Message Submission Agent ([RFC5598], Section 4.3.1). + + MUA: Message User Agent ([RFC5598], Section 4.2.1). + + RR: A DNS Resource Record + + RRset: A set of DNS Resource Records for a particular class, domain + and record type. + +1.2. Background + + The Domain Name System Security Extensions (DNSSEC) add data origin + authentication, data integrity and data non-existence proofs to the + Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034] + and [RFC4035]. + + As described in the introduction of [RFC6698], TLS authentication via + the existing public Certification Authority (CA) PKI suffers from an + over-abundance of trusted parties capable of issuing certificates for + any domain of their choice. DANE leverages the DNSSEC infrastructure + to publish trusted public keys and certificates for use with the + Transport Layer Security (TLS) [RFC5246] protocol via a new "TLSA" + DNS record type. With DNSSEC each domain can only vouch for the keys + of its directly delegated sub-domains. + + The TLS protocol enables secure TCP communication. In the context of + this memo, channel security is assumed to be provided by TLS. Used + without authentication, TLS provides only privacy protection against + eavesdropping attacks. With authentication, TLS also provides data + integrity protection to guard against MITM attacks. + + + + + + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 5] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + +1.3. SMTP channel security + + With HTTPS, Transport Layer Security (TLS) employs X.509 certificates + [RFC5280] issued by one of the many Certificate Authorities (CAs) + bundled with popular web browsers to allow users to authenticate + their "secure" websites. Before we specify a new DANE TLS security + model for SMTP, we will explain why a new security model is needed. + In the process, we will explain why the familiar HTTPS security model + is inadequate to protect inter-domain SMTP traffic. + + The subsections below outline four key problems with applying + traditional PKI to SMTP that are addressed by this specification. + Since SMTP channel security policy is not explicitly specified in + either the recipient address or the MX record, a new signaling + mechanism is required to indicate when channel security is possible + and should be used. The publication of TLSA records allows server + operators to securely signal to SMTP clients that TLS is available + and should be used. DANE TLSA makes it possible to simultaneously + discover which destination domains support secure delivery via TLS + and how to verify the authenticity of the associated SMTP services, + providing a path forward to ubiquitous SMTP channel security. + +1.3.1. STARTTLS downgrade attack + + The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop + protocol in a multi-hop store & forward email delivery process. SMTP + envelope recipient addresses are not transport addresses and are + security-agnostic. Unlike the Hypertext Transfer Protocol (HTTP) and + its corresponding secured version, HTTPS, where the use of TLS is + signaled via the URI scheme, email recipient addresses do not + directly signal transport security policy. Indeed, no such signaling + could work well with SMTP since TLS encryption of SMTP protects email + traffic on a hop-by-hop basis while email addresses could only + express end-to-end policy. + + With no mechanism available to signal transport security policy, SMTP + relays employ a best-effort "opportunistic" security model for TLS. + A single SMTP server TCP listening endpoint can serve both TLS and + non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS + command ([RFC3207]). The server signals TLS support to the client + over a cleartext SMTP connection, and, if the client also supports + TLS, it may negotiate a TLS encrypted channel to use for email + transmission. The server's indication of TLS support can be easily + suppressed by an MITM attacker. Thus pre-DANE SMTP TLS security can + be subverted by simply downgrading a connection to cleartext. No TLS + security feature, such as the use of PKIX, can prevent this. The + attacker can simply disable TLS. + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 6] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + +1.3.2. Insecure server name without DNSSEC + + With SMTP, DNS Mail Exchange (MX) records abstract the next-hop + transport endpoint and allow administrators to specify a set of + target servers to which SMTP traffic should be directed for a given + domain. + + A PKIX TLS client is vulnerable to MITM attacks unless it verifies + that the server's certificate binds the public key to a name that + matches one of the client's reference identifiers. A natural choice + of reference identifier is the server's domain name. However, with + SMTP, server names are obtained indirectly via MX records. Without + DNSSEC, the MX lookup is vulnerable to MITM and DNS cache poisoning + attacks. Active attackers can forge DNS replies with fake MX records + and can redirect email to servers with names of their choice. + Therefore, secure verification of SMTP TLS certificates matching the + server name is not possible without DNSSEC. + + One might try to harden TLS for SMTP against DNS attacks by using the + envelope recipient domain as a reference identifier and requiring + each SMTP server to possess a trusted certificate for the envelope + recipient domain rather than the MX hostname. Unfortunately, this is + impractical as email for many domains is handled by third parties + that are not in a position to obtain certificates for all the domains + they serve. Deployment of the Server Name Indication (SNI) extension + to TLS (see [RFC6066] Section 3) is no panacea, since SNI key + management is operationally challenging except when the email service + provider is also the domain's registrar and its certificate issuer; + this is rarely the case for email. + + Since the recipient domain name cannot be used as the SMTP server + reference identifier, and neither can the MX hostname without DNSSEC, + large-scale deployment of authenticated TLS for SMTP requires that + the DNS be secure. + + Since SMTP security depends critically on DNSSEC, it is important to + point out that consequently SMTP with DANE is the most conservative + possible trust model. It trusts only what must be trusted and no + more. Adding any other trusted actors to the mix can only reduce + SMTP security. A sender may choose to further harden DNSSEC for + selected high-value receiving domains, by configuring explicit trust + anchors for those domains instead of relying on the chain of trust + from the root domain. Detailed discussion of DNSSEC security + practices is out of scope for this document. + +1.3.3. Sender policy does not scale + + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 7] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + Sending systems are in some cases explicitly configured to use TLS + for mail sent to selected peer domains. This requires sending MTAs + to be configured with appropriate subject names or certificate + content digests to expect in the presented server certificates. + Because of the heavy administrative burden, such statically + configured SMTP secure channels are used rarely (generally only + between domains that make bilateral arrangements with their business + partners). Internet email, on the other hand, requires regularly + contacting new domains for which security configurations cannot be + established in advance. + + The abstraction of the SMTP transport endpoint via DNS MX records, + often across organization boundaries, limits the use of public CA PKI + with SMTP to a small set of sender-configured peer domains. With + little opportunity to use TLS authentication, sending MTAs are rarely + configured with a comprehensive list of trusted CAs. SMTP services + that support STARTTLS often deploy X.509 certificates that are self- + signed or issued by a private CA. + +1.3.4. Too many certification authorities + + Even if it were generally possible to determine a secure server name, + the SMTP client would still need to verify that the server's + certificate chain is issued by a trusted Certification Authority (a + trust anchor). MTAs are not interactive applications where a human + operator can make a decision (wisely or otherwise) to selectively + disable TLS security policy when certificate chain verification + fails. With no user to "click OK", the MTAs list of public CA trust + anchors would need to be comprehensive in order to avoid bouncing + mail addressed to sites that employ unknown Certification + Authorities. + + On the other hand, each trusted CA can issue certificates for any + domain. If even one of the configured CAs is compromised or operated + by an adversary, it can subvert TLS security for all destinations. + Any set of CAs is simultaneously both overly inclusive and not + inclusive enough. + +2. Identifying applicable TLSA records + +2.1. DNS considerations + +2.1.1. DNS errors, bogus and indeterminate responses + + + + + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 8] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + An SMTP client that implements opportunistic DANE TLS per this + specification depends critically on the integrity of DNSSEC lookups, + as discussed in Section 1.3. This section lists the DNS resolver + requirements needed to avoid downgrade attacks when using + opportunistic DANE TLS. + + A DNS lookup may signal an error or return a definitive answer. A + security-aware resolver must be used for this specification. + Security-aware resolvers will indicate the security status of a DNS + RRset with one of four possible values defined in Section 4.3 of + [RFC4035]: "secure", "insecure", "bogus" and "indeterminate". In + [RFC4035] the meaning of the "indeterminate" security status is: + + An RRset for which the resolver is not able to determine whether + the RRset should be signed, as the resolver is not able to obtain + the necessary DNSSEC RRs. This can occur when the security-aware + resolver is not able to contact security-aware name servers for + the relevant zones. + + Note, the "indeterminate" security status has a conflicting + definition in section 5 of [RFC4033]. + + There is no trust anchor that would indicate that a specific + portion of the tree is secure. + + SMTP clients following this specification SHOULD NOT distinguish + between "insecure" and "indeterminate" in the [RFC4033] sense. Both + "insecure" and RFC4033 "indeterminate" are handled identically: in + either case unvalidated data for the query domain is all that is and + can be available, and authentication using the data is impossible. + In what follows, when we say "insecure", we include also DNS results + for domains that lie in a portion of the DNS tree for which there is + no applicable trust anchor. With the DNS root zone signed, we expect + that validating resolvers used by Internet-facing MTAs will be + configured with trust anchor data for the root zone. Therefore, + RFC4033-style "indeterminate" domains should be rare in practice. + From here on, when we say "indeterminate", it is exclusively in the + sense of [RFC4035]. + + As noted in section 4.3 of [RFC4035], a security-aware DNS resolver + MUST be able to determine whether a given non-error DNS response is + "secure", "insecure", "bogus" or "indeterminate". It is expected + that most security-aware stub resolvers will not signal an + "indeterminate" security status in the RFC4035-sense to the + application, and will signal a "bogus" or error result instead. If a + resolver does signal an RFC4035 "indeterminate" security status, this + MUST be treated by the SMTP client as though a "bogus" or error + result had been returned. + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 9] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + An MTA making use of a non-validating security-aware stub resolver + MAY use the stub resolver's ability, if available, to signal DNSSEC + validation status based on information the stub resolver has learned + from an upstream validating recursive resolver. In accordance with + section 4.9.3 of [RFC4035]: + + ... a security-aware stub resolver MUST NOT place any reliance on + signature validation allegedly performed on its behalf, except + when the security-aware stub resolver obtained the data in question + from a trusted security-aware recursive name server via a secure + channel. + + To avoid much repetition in the text below, we will pause to explain + the handling of "bogus" or "indeterminate" DNSSEC query responses. + These are not necessarily the result of a malicious actor; they can, + for example, occur when network packets are corrupted or lost in + transit. Therefore, "bogus" or "indeterminate" replies are equated + in this memo with lookup failure. + + There is an important non-failure condition we need to highlight in + addition to the obvious case of the DNS client obtaining a non-empty + "secure" or "insecure" RRset of the requested type. Namely, it is + not an error when either "secure" or "insecure" non-existence is + determined for the requested data. When a DNSSEC response with a + validation status that is either "secure" or "insecure" reports + either no records of the requested type or non-existence of the query + domain, the response is not a DNS error condition. The DNS client + has not been left without an answer; it has learned that records of + the requested type do not exist. + + Security-aware stub resolvers will, of course, also signal DNS lookup + errors in other cases, for example when processing a "ServFail" + RCODE, which will not have an associated DNSSEC status. All lookup + errors are treated the same way by this specification, regardless of + whether they are from a "bogus" or "indeterminate" DNSSEC status or + from a more generic DNS error: the information that was requested + cannot be obtained by the security-aware resolver at this time. A + lookup error is thus a failure to obtain the relevant RRset if it + exists, or to determine that no such RRset exists when it does not. + + In contrast to a "bogus" or an "indeterminate" response, an + "insecure" DNSSEC response is not an error, rather it indicates that + the target DNS zone is either securely opted out of DNSSEC validation + or is not connected with the DNSSEC trust anchors being used. + Insecure results will leave the SMTP client with degraded channel + security, but do not stand in the way of message delivery. See + section Section 2.2 for further details. + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 10] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + +2.1.2. DNS error handling + + When a DNS lookup failure (error or "bogus" or "indeterminate" as + defined above) prevents an SMTP client from determining which SMTP + server or servers it should connect to, message delivery MUST be + delayed. This naturally includes, for example, the case when a + "bogus" or "indeterminate" response is encountered during MX + resolution. When multiple MX hostnames are obtained from a + successful MX lookup, but a later DNS lookup failure prevents network + address resolution for a given MX hostname, delivery may proceed via + any remaining MX hosts. + + When a particular SMTP server is securely identified as the delivery + destination, a set of DNS lookups (Section 2.2) MUST be performed to + locate any related TLSA records. If any DNS queries used to locate + TLSA records fail (be it due to "bogus" or "indeterminate" records, + timeouts, malformed replies, ServFails, etc.), then the SMTP client + MUST treat that server as unreachable and MUST NOT deliver the + message via that server. If no servers are reachable, delivery is + delayed. + + In what follows, we will only describe what happens when all relevant + DNS queries succeed. If any DNS failure occurs, the SMTP client MUST + behave as described in this section, by skipping the problem SMTP + server, or the problem destination. Queries for candidate TLSA + records are explicitly part of "all relevant DNS queries" and SMTP + clients MUST NOT continue to connect to an SMTP server or destination + whose TLSA record lookup fails. + +2.1.3. Stub resolver considerations + + A note about DNAME aliases: a query for a domain name whose ancestor + domain is a DNAME alias returns the DNAME RR for the ancestor domain, + along with a CNAME that maps the query domain to the corresponding + sub-domain of the target domain of the DNAME alias [RFC6672]. + Therefore, whenever we speak of CNAME aliases, we implicitly allow + for the possibility that the alias in question is the result of an + ancestor domain DNAME record. Consequently, no explicit support for + DNAME records is needed in SMTP software, it is sufficient to process + the resulting CNAME aliases. DNAME records only require special + processing in the validating stub-resolver library that checks the + integrity of the combined DNAME + CNAME reply. When DNSSEC + validation is handled by a local caching resolver, rather than the + MTA itself, even that part of the DNAME support logic is outside the + MTA. + + When a stub resolver returns a response containing a CNAME alias that + does not also contain the corresponding query results for the target + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 11] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + of the alias, the SMTP client will need to repeat the query at the + target of the alias, and should do so recursively up to some + configured or implementation-dependent recursion limit. If at any + stage of CNAME expansion an error is detected, the lookup of the + original requested records MUST be considered to have failed. + + Whether a chain of CNAME records was returned in a single stub + resolver response or via explicit recursion by the SMTP client, if at + any stage of recursive expansion an "insecure" CNAME record is + encountered, then it and all subsequent results (in particular, the + final result) MUST be considered "insecure" regardless of whether any + earlier CNAME records leading to the "insecure" record were "secure". + + Note, a security-aware non-validating stub resolver may return to the + SMTP client an "insecure" reply received from a validating recursive + resolver that contains a CNAME record along with additional answers + recursively obtained starting at the target of the CNAME. In this + all that one can say is that some record in the set of records + returned is "insecure", but it is possible that the initial CNAME + record and a subset of the subsequent records are "secure". + + If the SMTP client needs to determine the security status of the DNS + zone containing the initial CNAME record, it may need to issue an a + separate query of type "CNAME" that returns only the initial CNAME + record. In particular in Section 2.2.2 when insecure A or AAAA + records are found for an SMTP server via a CNAME alias, it may be + necessary to perform an additional CNAME query to determine whether + the DNS zone in which the alias is published is signed. + +2.2. TLS discovery + + As noted previously (in Section 1.3.1), opportunistic TLS with SMTP + servers that advertise TLS support via STARTTLS is subject to an MITM + downgrade attack. Also some SMTP servers that are not, in fact, TLS + capable erroneously advertise STARTTLS by default and clients need to + be prepared to retry cleartext delivery after STARTTLS fails. In + contrast, DNSSEC validated TLSA records MUST NOT be published for + servers that do not support TLS. Clients can safely interpret their + presence as a commitment by the server operator to implement TLS and + STARTTLS. + + This memo defines four actions to be taken after the search for a + TLSA record returns secure usable results, secure unusable results, + insecure or no results or an error signal. The term "usable" in this + context is in the sense of Section 4.1 of [RFC6698]. Specifically, + if the DNS lookup for a TLSA record returns: + + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 12] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + A secure TLSA RRset with at least one usable record: A connection to + the MTA MUST be made using authenticated and encrypted TLS, using + the techniques discussed in the rest of this document. Failure to + establish an authenticated TLS connection MUST result in falling + back to the next SMTP server or delayed delivery. + + A Secure non-empty TLSA RRset where all the records are unusable: A + connection to the MTA MUST be made via TLS, but authentication is + not required. Failure to establish an encrypted TLS connection + MUST result in falling back to the next SMTP server or delayed + delivery. + + An insecure TLSA RRset or DNSSEC validated proof-of-non-existent TLSA + records: + A connection to the MTA SHOULD be made using (pre-DANE) + opportunistic TLS, this includes using cleartext delivery when the + remote SMTP server does not appear to support TLS. The MTA MAY + retry in cleartext when delivery via TLS fails either during the + handshake or even during data transfer. + + Any lookup error: Lookup errors, including "bogus" and + "indeterminate", as explained in Section 2.1.1 MUST result in + falling back to the next SMTP server or delayed delivery. + + An SMTP client MAY be configured to require DANE verified delivery + for some destinations. We will call such a configuration "mandatory + DANE TLS". With mandatory DANE TLS, delivery proceeds only when + "secure" TLSA records are used to establish an encrypted and + authenticated TLS channel with the SMTP server. + + When the original next-hop destination is an address literal, rather + than a DNS domain, DANE TLS does not apply. Delivery proceeds using + any relevant security policy configured by the MTA administrator. + Similarly, when an MX RRset incorrectly lists a network address in + lieu of an MX hostname, if the MTA chooses to connect to the network + address DANE TLSA does not apply for such a connection. + + In the subsections that follow we explain how to locate the SMTP + servers and the associated TLSA records for a given next-hop + destination domain. We also explain which name or names are to be + used in identity checks of the SMTP server certificate. + +2.2.1. MX resolution + + In this section we consider next-hop domains that are subject to MX + resolution and have MX records. The TLSA records and the associated + base domain are derived separately for each MX hostname that is used + to attempt message delivery. DANE TLS can authenticate message + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 13] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + delivery to the intended next-hop domain only when the MX records are + obtained securely via a DNSSEC validated lookup. + + MX records MUST be sorted by preference; an MX hostname with a worse + (numerically higher) MX preference that has TLSA records MUST NOT + preempt an MX hostname with a better (numerically lower) preference + that has no TLSA records. In other words, prevention of delivery + loops by obeying MX preferences MUST take precedence over channel + security considerations. Even with two equal-preference MX records, + an MTA is not obligated to choose the MX hostname that offers more + security. Domains that want secure inbound mail delivery need to + ensure that all their SMTP servers and MX records are configured + accordingly. + + In the language of [RFC5321] Section 5.1, the original next-hop + domain is the "initial name". If the MX lookup of the initial name + results in a CNAME alias, the MTA replaces the initial name with the + resulting name and performs a new lookup with the new name. MTAs + typically support recursion in CNAME expansion, so this replacement + is performed repeatedly until the ultimate non-CNAME domain is found. + + If the MX RRset (or any CNAME leading to it) is "insecure" (see + Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via + pre-DANE opportunistic TLS. That said, the protocol in this memo is + an "opportunistic security" protocol, meaning that it strives to + communicate with each peer as securely as possible, while maintaining + broad interoperability. Therefore, the SMTP client MAY proceed to + use DANE TLS (as described in Section 2.2.2 below) even with MX hosts + obtained via an "insecure" MX RRset. For example, when a hosting + provider has a signed DNS zone and publishes TLSA records for its + SMTP servers, hosted domains that are not signed may still benefit + from the provider's TLSA records. Deliveries via the provider's SMTP + servers will not be subject to active attacks when sending SMTP + clients elect to make use of the provider's TLSA records. + + When the MX records are not (DNSSEC) signed, an active attacker can + redirect SMTP clients to MX hosts of his choice. Such redirection is + tamper-evident when SMTP servers found via "insecure" MX records are + recorded as the next-hop relay in the MTA delivery logs in their + original (rather than CNAME expanded) form. Sending MTAs SHOULD log + unexpanded MX hostnames when these result from insecure MX lookups. + Any successful authentication via an insecurely determined MX host + MUST NOT be misrepresented in the mail logs as secure delivery to the + intended next-hop domain. When DANE TLS is mandatory (Section 6) for + a given destination, delivery MUST be delayed when the MX RRset is + not "secure". + + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 14] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + Otherwise, assuming no DNS errors (Section 2.1.1), the MX RRset is + "secure", and the SMTP client MUST treat each MX hostname as a + separate non-MX destination for opportunistic DANE TLS as described + in Section 2.2.2. When, for a given MX hostname, no TLSA records are + found, or only "insecure" TLSA records are found, DANE TLSA is not + applicable with the SMTP server in question and delivery proceeds to + that host as with pre-DANE opportunistic TLS. To avoid downgrade + attacks, any errors during TLSA lookups MUST, as explained in + Section 2.1.1, cause the SMTP server in question to be treated as + unreachable. + +2.2.2. Non-MX destinations + + This section describes the algorithm used to locate the TLSA records + and associated TLSA base domain for an input domain not subject to MX + resolution. Such domains include: + + o Each MX hostname used in a message delivery attempt for an + original next-hop destination domain subject to MX resolution. + Note, MTAs are not obligated to support CNAME expansion of MX + hostnames. + + o Any administrator configured relay hostname, not subject to MX + resolution. This frequently involves configuration set by the MTA + administrator to handle some or all mail. + + o A next-hop destination domain subject to MX resolution that has no + MX records. In this case the domain's name is implicitly also its + sole SMTP server name. + + Note that DNS queries with type TLSA are mishandled by load balancing + nameservers that serve the MX hostnames of some large email + providers. The DNS zones served by these nameservers are not signed + and contain no TLSA records, but queries for TLSA records fail, + rather than returning the non-existence of the requested TLSA + records. + + To avoid problems delivering mail to domains whose SMTP servers are + served by the problem nameservers the SMTP client MUST perform any A + and/or AAAA queries for the destination before attempting to locate + the associated TLSA records. This lookup is needed in any case to + determine whether the destination domain is reachable and the DNSSEC + validation status of the chain of CNAME queries required to reach the + ultimate address records. + + If no address records are found, the destination is unreachable. If + address records are found, but the DNSSEC validation status of the + first query response is "insecure" (see Section 2.1.3), the SMTP + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 15] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + client SHOULD NOT proceed to search for any associated TLSA records. + With the problem domains, TLSA queries will lead to DNS lookup errors + and cause messages to be consistently delayed and ultimately returned + to the sender. We don't expect to find any "secure" TLSA records + associated with a TLSA base domain that lies in an unsigned DNS zone. + Therefore, skipping TLSA lookups in this case will also reduce + latency with no detrimental impact on security. + + If the A and/or AAAA lookup of the "initial name" yields a CNAME, we + replace it with the resulting name as if it were the initial name and + perform a lookup again using the new name. This replacement is + performed recursively. + + We consider the following cases for handling a DNS response for an A + or AAAA DNS lookup: + + Not found: When the DNS queries for A and/or AAAA records yield + neither a list of addresses nor a CNAME (or CNAME expansion is not + supported) the destination is unreachable. + + Non-CNAME: The answer is not a CNAME alias. If the address RRset + is "secure", TLSA lookups are performed as described in + Section 2.2.3 with the initial name as the candidate TLSA base + domain. If no "secure" TLSA records are found, DANE TLS is not + applicable and mail delivery proceeds with pre-DANE opportunistic + TLS (which, being best-effort, degrades to cleartext delivery when + STARTTLS is not available or the TLS handshake fails). + + Insecure CNAME: The input domain is a CNAME alias, but the ultimate + network address RRset is "insecure" (see Section 2.1.1). If the + initial CNAME response is also "insecure", DANE TLS does not + apply. Otherwise, this case is treated just like the non-CNAME + case above, where a search is performed for a TLSA record with the + original input domain as the candidate TLSA base domain. + + Secure CNAME: The input domain is a CNAME alias, and the ultimate + network address RRset is "secure" (see Section 2.1.1). Two + candidate TLSA base domains are tried: the fully CNAME-expanded + initial name and, failing that, then the initial name itself. + + + + + + + + + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 16] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + In summary, if it is possible to securely obtain the full, CNAME- + expanded, DNSSEC-validated address records for the input domain, then + that name is the preferred TLSA base domain. Otherwise, the + unexpanded input-MX domain is the candidate TLSA base domain. When + no "secure" TLSA records are found at either the CNAME-expanded or + unexpanded domain, then DANE TLS does not apply for mail delivery via + the input domain in question. And, as always, errors, bogus or + indeterminate results for any query in the process MUST result in + delaying or abandoning delivery. + +2.2.3. TLSA record lookup + + Each candidate TLSA base domain (the original or fully CNAME-expanded + name of a non-MX destination or a particular MX hostname of an MX + destination) is in turn prefixed with service labels of the form + "_<port>._tcp". The resulting domain name is used to issue a DNSSEC + query with the query type set to TLSA ([RFC6698] Section 7.1). + + For SMTP, the destination TCP port is typically 25, but this may be + different with custom routes specified by the MTA administrator in + which case the SMTP client MUST use the appropriate number in the + "_<port>" prefix in place of "_25". If, for example, the candidate + base domain is "mx.example.com", and the SMTP connection is to port + 25, the TLSA RRset is obtained via a DNSSEC query of the form: + + _25._tcp.mx.example.com. IN TLSA ? + + The query response may be a CNAME, or the actual TLSA RRset. If the + response is a CNAME, the SMTP client (through the use of its + security-aware stub resolver) restarts the TLSA query at the target + domain, following CNAMEs as appropriate and keeping track of whether + the entire chain is "secure". If any "insecure" records are + encountered, or the TLSA records don't exist, the next candidate TLSA + base is tried instead. + + If the ultimate response is a "secure" TLSA RRset, then the candidate + TLSA base domain will be the actual TLSA base domain and the TLSA + RRset will constitute the TLSA records for the destination. If none + of the candidate TLSA base domains yield "secure" TLSA records then + delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients + MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades + or even to skip SMTP servers that fail authentication, but MUST NOT + misrepresent authentication success as either a secure connection to + the SMTP server or as a secure delivery to the intended next-hop + domain. + + TLSA record publishers may leverage CNAMEs to reference a single + authoritative TLSA RRset specifying a common Certification Authority + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 17] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + or a common end entity certificate to be used with multiple TLS + services. Such CNAME expansion does not change the SMTP client's + notion of the TLSA base domain; thus, when _25._tcp.mx.example.com is + a CNAME, the base domain remains mx.example.com and this is still the + reference identifier used together with the next-hop domain in peer + certificate name checks. + + Note, shared end entity certificate associations expose the + publishing domain to substitution attacks, where an MITM attacker can + reroute traffic to a different server that shares the same end entity + certificate. Such shared end entity records SHOULD be avoided unless + the servers in question are functionally equivalent (an active + attacker gains nothing by diverting client traffic from one such + server to another). + + For example, given the DNSSEC validated records below: + + example.com. IN MX 0 mx1.example.com. + example.com. IN MX 0 mx2.example.com. + _25._tcp.mx1.example.com. IN CNAME tlsa211._dane.example.com. + _25._tcp.mx2.example.com. IN CNAME tlsa211._dane.example.com. + tlsa211._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c149a... + + The SMTP servers mx1.example.com and mx2.example.com will be expected + to have certificates issued under a common trust anchor, but each MX + hostname's TLSA base domain remains unchanged despite the above CNAME + records. Correspondingly, each SMTP server will be associated with a + pair of reference identifiers consisting of its hostname plus the + next-hop domain "example.com". + + If, during TLSA resolution (including possible CNAME indirection), at + least one "secure" TLSA record is found (even if not usable because + it is unsupported by the implementation or support is + administratively disabled), then the corresponding host has signaled + its commitment to implement TLS. The SMTP client MUST NOT deliver + mail via the corresponding host unless a TLS session is negotiated + via STARTTLS. This is required to avoid MITM STARTTLS downgrade + attacks. + + As noted previously (in Section Section 2.2.2), when no "secure" TLSA + records are found at the fully CNAME-expanded name, the original + unexpanded name MUST be tried instead. This supports customers of + hosting providers where the provider's zone cannot be validated with + DNSSEC, but the customer has shared appropriate key material with the + hosting provider to enable TLS via SNI. Intermediate names that + arise during CNAME expansion that are neither the original, nor the + final name, are never candidate TLSA base domains, even if "secure". + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 18] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + +3. DANE authentication + + This section describes which TLSA records are applicable to SMTP + opportunistic DANE TLS and how to apply such records to authenticate + the SMTP server. With opportunistic DANE TLS, both the TLS support + implied by the presence of DANE TLSA records and the verification + parameters necessary to authenticate the TLS peer are obtained + together. In contrast to protocols where channel security policy is + set exclusively by the client, authentication via this protocol is + expected to be less prone to connection failure caused by + incompatible configuration of the client and server. + +3.1. TLSA certificate usages + + The DANE TLSA specification [RFC6698] defines multiple TLSA RR types + via combinations of 3 numeric parameters. The numeric values of + these parameters were later given symbolic names in + [I-D.ietf-dane-registry-acronyms]. The rest of the TLSA record is + the "certificate association data field", which specifies the full or + digest value of a certificate or public key. The parameters are: + + The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698] + specifies 4 values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE- + EE(3). There is an additional private-use value: PrivCert(255). + All other values are reserved for use by future specifications. + + The selector field: Section 2.1.2 of [RFC6698] specifies 2 values: + Cert(0), SPKI(1). There is an additional private-use value: + PrivSel(255). All other values are reserved for use by future + specifications. + + The matching type field: Section 2.1.3 of [RFC6698] specifies 3 + values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional + private-use value: PrivMatch(255). All other values are reserved + for use by future specifications. + + We may think of TLSA Certificate Usage values 0 through 3 as a + combination of two one-bit flags. The low bit chooses between trust + anchor (TA) and end entity (EE) certificates. The high bit chooses + between public PKI issued and domain-issued certificates. + + The selector field specifies whether the TLSA RR matches the whole + certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1). The + subjectPublicKeyInfo is an ASN.1 DER encoding of the certificate's + algorithm id, any parameters and the public key data. + + The matching type field specifies how the TLSA RR Certificate + Association Data field is to be compared with the certificate or + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 19] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + public key. A value of Full(0) means an exact match: the full DER + encoding of the certificate or public key is given in the TLSA RR. A + value of SHA2-256(1) means that the association data matches the + SHA2-256 digest of the certificate or public key, and likewise + SHA2-512(2) means a SHA2-512 digest is used. + + Since opportunistic DANE TLS will be used by non-interactive MTAs, + with no user to "press OK" when authentication fails, reliability of + peer authentication is paramount. Server operators are advised to + publish TLSA records that are least likely to fail authentication due + to interoperability or operational problems. Because DANE TLS relies + on coordinated changes to DNS and SMTP server settings, the best + choice of records to publish will depend on site-specific practices. + + The certificate usage element of a TLSA record plays a critical role + in determining how the corresponding certificate association data + field is used to authenticate server's certificate chain. The next + two subsections explain the process for certificate usages DANE-EE(3) + and DANE-TA(2). The third subsection briefly explains why + certificate usages PKIX-TA(0) and PKIX-EE(1) are not applicable with + opportunistic DANE TLS. + + In summary, we recommend the use of either "DANE-EE(3) SPKI(1) + SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records + depending on site needs. Other combinations of TLSA parameters are + either explicitly unsupported, or offer little to recommend them over + these two. + + The mandatory to support digest algorithm in [RFC6698] is + SHA2-256(1). When the server's TLSA RRset includes records with a + matching type indicating a digest record (i.e., a value other than + Full(0)), a TLSA record with a SHA2-256(1) matching type SHOULD be + provided along with any other digest published, since some SMTP + clients may support only SHA2-256(1). If at some point the SHA2-256 + digest algorithm is tarnished by new cryptanalytic attacks, + publishers will need to include an appropriate stronger digest in + their TLSA records, initially along with, and ultimately in place of, + SHA2-256. + +3.1.1. Certificate usage DANE-EE(3) + + Authentication via certificate usage DANE-EE(3) TLSA records involves + simply checking that the server's leaf certificate matches the TLSA + record. In particular the binding of the server public key to its + name is based entirely on the TLSA record association. The server + MUST be considered authenticated even if none of the names in the + certificate match the client's reference identity for the server. + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 20] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + Similarly, the expiration date of the server certificate MUST be + ignored, the validity period of the TLSA record key binding is + determined by the validity interval of the TLSA record DNSSEC + signature. + + With DANE-EE(3) servers need not employ SNI (may ignore the client's + SNI message) even when the server is known under independent names + that would otherwise require separate certificates. It is instead + sufficient for the TLSA RRsets for all the domains in question to + match the server's default certificate. Of course with SMTP servers + it is simpler still to publish the same MX hostname for all the + hosted domains. + + For domains where it is practical to make coordinated changes in DNS + TLSA records during SMTP server key rotation, it is often best to + publish end-entity DANE-EE(3) certificate associations. DANE-EE(3) + certificates don't suddenly stop working when leaf or intermediate + certificates expire, and don't fail when the server operator neglects + to configure all the required issuer certificates in the server + certificate chain. + + TLSA records published for SMTP servers SHOULD, in most cases, be + "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE + implementations are required to support SHA2-256, this record type + works for all clients and need not change across certificate renewals + with the same key. + +3.1.2. Certificate usage DANE-TA(2) + + Some domains may prefer to avoid the operational complexity of + publishing unique TLSA RRs for each TLS service. If the domain + employs a common issuing Certification Authority to create + certificates for multiple TLS services, it may be simpler to publish + the issuing authority as a trust anchor (TA) for the certificate + chains of all relevant services. The TLSA query domain (TLSA base + domain with port and protocol prefix labels) for each service issued + by the same TA may then be set to a CNAME alias that points to a + common TLSA RRset that matches the TA. For example: + + example.com. IN MX 0 mx1.example.com. + example.com. IN MX 0 mx2.example.com. + _25._tcp.mx1.example.com. IN CNAME tlsa211._dane.example.com. + _25._tcp.mx2.example.com. IN CNAME tlsa211._dane.example.com. + tlsa211._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c14.... + + + + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 21] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + With usage DANE-TA(2) the server certificates will need to have names + that match one of the client's reference identifiers (see [RFC6125]). + The server MAY employ SNI to select the appropriate certificate to + present to the client. + + SMTP servers that rely on certificate usage DANE-TA(2) TLSA records + for TLS authentication MUST include the TA certificate as part of the + certificate chain presented in the TLS handshake server certificate + message even when it is a self-signed root certificate. At this + time, many SMTP servers are not configured with a comprehensive list + of trust anchors, nor are they expected to at any point in the + future. Some MTAs will ignore all locally trusted certificates when + processing usage DANE-TA(2) TLSA records. Thus even when the TA + happens to be a public Certification Authority known to the SMTP + client, authentication is likely to fail unless the TA certificate is + included in the TLS server certificate message. + + TLSA records with selector Full(0) are discouraged. While these + potentially obviate the need to transmit the TA certificate in the + TLS server certificate message, client implementations may not be + able to augment the server certificate chain with the data obtained + from DNS, especially when the TLSA record supplies a bare key + (selector SPKI(1)). Since the server will need to transmit the TA + certificate in any case, server operators SHOULD publish TLSA records + with a selector other than Full(0) and avoid potential + interoperability issues with large TLSA records containing full + certificates or keys. + + TLSA Publishers employing DANE-TA(2) records SHOULD publish records + with a selector of Cert(0). Such TLSA records are associated with + the whole trust anchor certificate, not just with the trust anchor + public key. In particular, the SMTP client SHOULD then apply any + relevant constraints from the trust anchor certificate, such as, for + example, path length constraints. + + While a selector of SPKI(1) may also be employed, the resulting TLSA + record will not specify the full trust anchor certificate content, + and elements of the trust anchor certificate other than the public + key become mutable. This may, for example, allow a subsidiary CA to + issue a chain that violates the trust anchor's path length or name + constraints. + +3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) + + As noted in the introduction, SMTP clients cannot, without relying on + DNSSEC for secure MX records and DANE for STARTTLS support signaling, + perform server identity verification or prevent STARTTLS downgrade + attacks. The use of PKIX CAs offers no added security since an + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 22] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + attacker capable of compromising DNSSEC is free to replace any PKIX- + TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient + non-PKIX certificate usage. + + SMTP servers SHOULD NOT publish TLSA RRs with certificate usage PKIX- + TA(0) or PKIX-EE(1). SMTP clients cannot be expected to be + configured with a suitably complete set of trusted public CAs. + Lacking a complete set of public CAs, clients would not be able to + verify the certificates of SMTP servers whose issuing root CAs are + not trusted by the client. + + Opportunistic DANE TLS needs to interoperate without bilateral + coordination of security settings between client and server systems. + Therefore, parameter choices that are fragile in the absence of + bilateral coordination are unsupported. Nothing is lost since the + PKIX certificate usages cannot aid SMTP TLS security, they can only + impede SMTP TLS interoperability. + + SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0) + or PKIX-EE(1) is undefined. SMTP clients should generally treat such + TLSA records as unusable. + +3.2. Certificate matching + + When at least one usable "secure" TLSA record is found, the SMTP + client MUST use TLSA records to authenticate the SMTP server. + Messages MUST NOT be delivered via the SMTP server if authentication + fails, otherwise the SMTP client is vulnerable to MITM attacks. + +3.2.1. DANE-EE(3) name checks + + The SMTP client MUST NOT perform certificate name checks with + certificate usage DANE-EE(3), see Section 3.1.1 above. + +3.2.2. DANE-TA(2) name checks + + To match a server via a TLSA record with certificate usage DANE- + TA(2), the client MUST perform name checks to ensure that it has + reached the correct server. In all DANE-TA(2) cases the SMTP client + MUST include the TLSA base domain as one of the valid reference + identifiers for matching the server certificate. + + TLSA records for MX hostnames: If the TLSA base domain was obtained + indirectly via a "secure" MX lookup (including any CNAME-expanded + name of an MX hostname), then the original next-hop domain used in + the MX lookup MUST be included as as a second reference + identifier. The CNAME-expanded original next-hop domain MUST be + included as a third reference identifier if different from the + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 23] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + original next-hop domain. When the client MTA is employing DANE + TLS security despite "insecure" MX redirection the MX hostname is + the only reference identifier. + + TLSA records for Non-MX hostnames: If MX records were not used + (e.g., if none exist) and the TLSA base domain is the CNAME- + expanded original next-hop domain, then the original next-hop + domain MUST be included as a second reference identifier. + + Accepting certificates with the original next-hop domain in addition + to the MX hostname allows a domain with multiple MX hostnames to + field a single certificate bearing a single domain name (i.e., the + email domain) across all the SMTP servers. This also aids + interoperability with pre-DANE SMTP clients that are configured to + look for the email domain name in server certificates. For example, + with "secure" DNS records as below: + + exchange.example.org. IN CNAME mail.example.org. + mail.example.org. IN CNAME example.com. + example.com. IN MX 10 mx10.example.com. + example.com. IN MX 15 mx15.example.com. + example.com. IN MX 20 mx20.example.com. + ; + mx10.example.com. IN A 192.0.2.10 + _25._tcp.mx10.example.com. IN TLSA 2 0 1 ... + ; + mx15.example.com. IN CNAME mxbackup.example.com. + mxbackup.example.com. IN A 192.0.2.15 + ; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN) + _25._tcp.mx15.example.com. IN TLSA 2 0 1 ... + ; + mx20.example.com. IN CNAME mxbackup.example.net. + mxbackup.example.net. IN A 198.51.100.20 + _25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ... + + Certificate name checks for delivery of mail to exchange.example.org + via any of the associated SMTP servers MUST accept at least the names + "exchange.example.org" and "example.com", which are respectively the + original and fully expanded next-hop domain. When the SMTP server is + mx10.example.com, name checks MUST accept the TLSA base domain + "mx10.example.com". If, despite the fact that MX hostnames are + required to not be aliases, the MTA supports delivery via + "mx15.example.com" or "mx20.example.com" then name checks MUST accept + the respective TLSA base domains "mx15.example.com" and + "mxbackup.example.net". + +3.2.3. Reference identifier matching + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 24] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + When name checks are applicable (certificate usage DANE-TA(2)), if + the server certificate contains a Subject Alternative Name extension + ([RFC5280]), with at least one DNS-ID ([RFC6125]) then only the DNS- + IDs are matched against the client's reference identifiers. The CN- + ID ([RFC6125]) is only considered when no DNS-IDs are present. The + server certificate is considered matched when one of its presented + identifiers ([RFC5280]) matches any of the client's reference + identifiers. + + Wildcards are valid in either DNS-IDs or the CN-ID when applicable. + The wildcard character must be entire first label of the DNS-ID or + CN-ID. Thus, "*.example.com" is valid, while "smtp*.example.com" and + "*smtp.example.com" are not. SMTP clients MUST support wildcards + that match the first label of the reference identifier, with the + remaining labels matching verbatim. For example, the DNS-ID + "*.example.com" matches the reference identifier "mx1.example.com". + SMTP clients MAY, subject to local policy allow wildcards to match + multiple reference identifier labels, but servers cannot expect broad + support for such a policy. Therefore any wildcards in server + certificates SHOULD match exactly one label in either the TLSA base + domain or the next-hop domain. + +4. Server key management + + Two TLSA records MUST be published before employing a new EE or TA + public key or certificate, one matching the currently deployed key + and the other matching the new key scheduled to replace it. Once + sufficient time has elapsed for all DNS caches to expire the previous + TLSA RRset and related signature RRsets, servers may be configured to + use the new EE private key and associated public key certificate or + may employ certificates signed by the new trust anchor. + + Once the new public key or certificate is in use, the TLSA RR that + matches the retired key can be removed from DNS, leaving only RRs + that match keys or certificates in active use. + + As described in Section 3.1.2, when server certificates are validated + via a DANE-TA(2) trust anchor, and CNAME records are employed to + store the TA association data at a single location, the + responsibility of updating the TLSA RRset shifts to the operator of + the trust anchor. Before a new trust anchor is used to sign any new + server certificates, its certificate (digest) is added to the + relevant TLSA RRset. After enough time elapses for the original TLSA + RRset to age out of DNS caches, the new trust anchor can start + issuing new server certificates. Once all certificates issued under + the previous trust anchor have expired, its associated RRs can be + removed from the TLSA RRset. + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 25] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + In the DANE-TA(2) key management model server operators do not + generally need to update DNS TLSA records after initially creating a + CNAME record that references the centrally operated DANE-TA(2) RRset. + If a particular server's key is compromised, its TLSA CNAME SHOULD be + replaced with a DANE-EE(3) association until the certificate for the + compromised key expires, at which point it can return to using CNAME + record. If the central trust anchor is compromised, all servers need + to be issued new keys by a new TA, and a shared DANE-TA(2) TLSA RRset + needs to be published containing just the new TA. SMTP servers + cannot expect broad SMTP client CRL or OCSP support. + +5. Digest algorithm agility + + While [RFC6698] specifies multiple digest algorithms, it does not + specify a protocol by which the SMTP client and TLSA record publisher + can agree on the strongest shared algorithm. Such a protocol would + allow the client and server to avoid exposure to any deprecated + weaker algorithms that are published for compatibility with less + capable clients, but should be ignored when possible. We specify + such a protocol below. + + Suppose that a DANE TLS client authenticating a TLS server considers + digest algorithm "BetterAlg" stronger than digest algorithm + "WorseAlg". Suppose further that a server's TLSA RRset contains some + records with "BetterAlg" as the digest algorithm. Finally, suppose + that for every raw public key or certificate object that is included + in the server's TLSA RRset in digest form, whenever that object + appears with algorithm "WorseAlg" with some usage and selector it + also appears with algorithm "BetterAlg" with the same usage and + selector. In that case our client can safely ignore TLSA records + with the weaker algorithm "WorseAlg", because it suffices to check + the records with the stronger algorithm "BetterAlg". + + Server operators MUST ensure that for any given usage and selector, + each object (certificate or public key), for which a digest + association exists in the TLSA RRset, is published with the SAME SET + of digest algorithms as all other objects that published with that + usage and selector. In other words, for each usage and selector, the + records with non-zero matching types will correspond to on a cross- + product of a set of underlying objects and a fixed set of digest + algorithms that apply uniformly to all the objects. + + To achieve digest algorithm agility, all published TLSA RRsets for + use with opportunistic DANE TLS for SMTP MUST conform to the above + requirements. Then, for each combination of usage and selector, SMTP + clients can simply ignore all digest records except those that employ + the strongest digest algorithm. The ordering of digest algorithms by + strength is not specified in advance, it is entirely up to the SMTP + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 26] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + client. SMTP client implementations SHOULD make the digest algorithm + preference order configurable. Only the future will tell which + algorithms might be weakened by new attacks and when. + + Note, TLSA records with a matching type of Full(0), that publish the + full value of a certificate or public key object, play no role in + digest algorithm agility. They neither trump the processing of + records that employ digests, nor are they ignored in the presence of + any records with a digest (i.e. non-zero) matching type. + + SMTP clients SHOULD use digest algorithm agility when processing the + DANE TLSA records of an SMTP server. Algorithm agility is to be + applied after first discarding any unusable or malformed records + (unsupported digest algorithm, or incorrect digest length). Thus, + for each usage and selector, the client SHOULD process only any + usable records with a matching type of Full(0) and the usable records + whose digest algorithm is believed to be the strongest among usable + records with the given usage and selector. + + The main impact of this requirement is on key rotation, when the TLSA + RRset is pre-populated with digests of new certificates or public + keys, before these replace or augment their predecessors. Were the + newly introduced RRs to include previously unused digest algorithms, + clients that employ this protocol could potentially ignore all the + digests corresponding to the current keys or certificates, causing + connectivity issues until the new keys or certificates are deployed. + Similarly, publishing new records with fewer digests could cause + problems for clients using cached TLSA RRsets that list both the old + and new objects once the new keys are deployed. + + To avoid problems, server operators SHOULD apply the following + strategy: + + o When changing the set of objects published via the TLSA RRset + (e.g. during key rotation), DO NOT change the set of digest + algorithms used; change just the list of objects. + + o When changing the set of digest algorithms, change only the set of + algorithms, and generate a new RRset in which all the current + objects are re-published with the new set of digest algorithms. + + After either of these two changes are made, the new TLSA RRset should + be left in place long enough that the older TLSA RRset can be flushed + from caches before making another change. + +6. Mandatory TLS Security + + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 27] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + An MTA implementing this protocol may require a stronger security + assurance when sending email to selected destinations. The sending + organization may need to send sensitive email and/or may have + regulatory obligations to protect its content. This protocol is not + in conflict with such a requirement, and in fact can often simplify + authenticated delivery to such destinations. + + Specifically, with domains that publish DANE TLSA records for their + MX hostnames, a sending MTA can be configured to use the receiving + domains's DANE TLSA records to authenticate the corresponding SMTP + server. Authentication via DANE TLSA records is easier to manage, as + changes in the receiver's expected certificate properties are made on + the receiver end and don't require manually communicated + configuration changes. With mandatory DANE TLS, when no usable TLSA + records are found, message delivery is delayed. Thus, mail is only + sent when an authenticated TLS channel is established to the remote + SMTP server. + + Administrators of mail servers that employ mandatory DANE TLS, need + to carefully monitor their mail logs and queues. If a partner domain + unwittingly misconfigures their TLSA records, disables DNSSEC, or + misconfigures SMTP server certificate chains, mail will be delayed + and may bounce if the issue is not resolved in a timely manner. + +7. Note on DANE for Message User Agents + + We note that the SMTP protocol is also used between Message User + Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In + [RFC6186] a protocol is specified that enables an MUA to dynamically + locate the MSA based on the user's email address. SMTP connection + security considerations for MUAs implementing [RFC6186] are largely + analogous to connection security requirements for MTAs, and this + specification could be applied largely verbatim with DNS MX records + replaced by corresponding DNS Service (SRV) records + [I-D.ietf-dane-srv]. + + However, until MUAs begin to adopt the dynamic configuration + mechanisms of [RFC6186] they are adequately served by more + traditional static TLS security policies. Specification of DANE TLS + for Message User Agent (MUA) to Message Submission Agent (MSA) SMTP + is left to future documents that focus specifically on SMTP security + between MUAs and MSAs. + + + + + + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 28] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + +8. Interoperability considerations + +8.1. SNI support + + To ensure that the server sends the right certificate chain, the SMTP + client MUST send the TLS SNI extension containing the TLSA base + domain. This precludes the use of the backward compatible SSL 2.0 + compatible SSL HELLO by the SMTP client. The minimum SSL/TLS client + HELLO version for SMTP clients performing DANE authentication is SSL + 3.0, but a client that offers SSL 3.0 MUST also offer at least TLS + 1.0 and MUST include the SNI extension. Servers that don't make use + of SNI MAY negotiate SSL 3.0 if offered by the client. + + Each SMTP server MUST present a certificate chain (see [RFC5246] + Section 7.4.2) that matches at least one of the TLSA records. The + server MAY rely on SNI to determine which certificate chain to + present to the client. Clients that don't send SNI information may + not see the expected certificate chain. + + If the server's TLSA records match the server's default certificate + chain, the server need not support SNI. In either case, the server + need not include the SNI extension in its TLS HELLO as simply + returning a matching certificate chain is sufficient. Servers MUST + NOT enforce the use of SNI by clients, as the client may be using + unauthenticated opportunistic TLS and may not expect any particular + certificate from the server. If the client sends no SNI extension, + or sends an SNI extension for an unsupported domain, the server MUST + simply send some fallback certificate chain of its choice. The + reason for not enforcing strict matching of the requested SNI + hostname is that DANE TLS clients are typically willing to accept + multiple server names, but can only send one name in the SNI + extension. The server's fallback certificate may match a different + name acceptable to the client, e.g., the original next-hop domain. + +8.2. Anonymous TLS cipher suites + + Since many SMTP servers either do not support or do not enable any + anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD + offer to negotiate a typical set of non-anonymous cipher suites + required for interoperability with such servers. An SMTP client + employing pre-DANE opportunistic TLS MAY in addition include one or + more anonymous TLS cipher suites in its TLS HELLO. SMTP servers, + that need to interoperate with opportunistic TLS clients SHOULD be + prepared to interoperate with such clients by either always selecting + a mutually supported non-anonymous cipher suite or by correctly + handling client connections that negotiate anonymous cipher suites. + + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 29] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + Note that while SMTP server operators are under no obligation to + enable anonymous cipher suites, no security is gained by sending + certificates to clients that will ignore them. Indeed support for + anonymous cipher suites in the server makes audit trails more + informative. Log entries that record connections that employed an + anonymous cipher suite record the fact that the clients did not care + to authenticate the server. + +9. Operational Considerations + +9.1. Client Operational Considerations + + An operational error on the sending or receiving side that cannot be + corrected in a timely manner may, at times, lead to consistent + failure to deliver time-sensitive email. The sending MTA + administrator may have to choose between letting email queue until + the error is resolved and disabling opportunistic or mandatory DANE + TLS for one or more destinations. The choice to disable DANE TLS + security should not be made lightly. Every reasonable effort should + be made to determine that problems with mail delivery are the result + of an operational error, and not an attack. A fallback strategy may + be to configure explicit out-of-band TLS security settings if + supported by the sending MTA. + + SMTP clients may deploy opportunistic DANE TLS incrementally by + enabling it only for selected sites, or may occasionally need to + disable opportunistic DANE TLS for peers that fail to interoperate + due to misconfiguration or software defects on either end. Some + implementations MAY support DANE TLS in an "audit only" mode in which + failure to achieve the requisite security level is logged as a + warning and delivery proceeds at a reduced security level. Unless + local policy specifies "audit only" or that opportunistic DANE TLS is + not to be used for a particular destination, an SMTP client MUST NOT + deliver mail via a server whose certificate chain fails to match at + least one TLSA record when usable TLSA records are found for that + server. + +9.2. Publisher Operational Considerations + + SMTP servers that publish certificate usage DANE-TA(2) associations + MUST include the TA certificate in their TLS server certificate + chain, even when that TA certificate is a self-signed root + certificate. + + TLSA Publishers must follow the digest agility guidelines in + Section 5 and must make sure that all objects published in digest + form for a particular usage and selector are published with the same + set of digest algorithms. + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 30] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + TLSA Publishers should follow the TLSA publication size guidance + found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines". + +10. Security Considerations + + This protocol leverages DANE TLSA records to implement MITM resistant + opportunistic channel security for SMTP. For destination domains + that sign their MX records and publish signed TLSA records for their + MX hostnames, this protocol allows sending MTAs to securely discover + both the availability of TLS and how to authenticate the destination. + + This protocol does not aim to secure all SMTP traffic, as that is not + practical until DNSSEC and DANE adoption are universal. The + incremental deployment provided by following this specification is a + best possible path for securing SMTP. This protocol coexists and + interoperates with the existing insecure Internet email backbone. + + The protocol does not preclude existing non-opportunistic SMTP TLS + security arrangements, which can continue to be used as before via + manual configuration with negotiated out-of-band key and TLS + configuration exchanges. + + Opportunistic SMTP TLS depends critically on DNSSEC for downgrade + resistance and secure resolution of the destination name. If DNSSEC + is compromised, it is not possible to fall back on the public CA PKI + to prevent MITM attacks. A successful breach of DNSSEC enables the + attacker to publish TLSA usage 3 certificate associations, and + thereby bypass any security benefit the legitimate domain owner might + hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of + public CA PKI support in existing MTA deployments, avoiding + certificate usages 0 and 1 simplifies implementation and deployment + with no adverse security consequences. + + Implementations must strictly follow the portions of this + specification that indicate when it is appropriate to initiate a non- + authenticated connection or cleartext connection to a SMTP server. + Specifically, in order to prevent downgrade attacks on this protocol, + implementation must not initiate a connection when this specification + indicates a particular SMTP server must be considered unreachable. + +11. IANA considerations + + This specification requires no support from IANA. + +12. Acknowledgements + + The authors would like to extend great thanks to Tony Finch, who + started the original version of a DANE SMTP document. His work is + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 31] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + greatly appreciated and has been incorporated into this document. + The authors would like to additionally thank Phil Pennock for his + comments and advice on this document. + + Acknowledgments from Viktor: Thanks to Paul Hoffman who motivated me + to begin work on this memo and provided feedback on early drafts. + Thanks to Patrick Koetter, Perry Metzger and Nico Williams for + valuable review comments. Thanks also to Wietse Venema who created + Postfix, and whose advice and feedback were essential to the + development of the Postfix DANE implementation. + +13. References + +13.1. Normative References + + [I-D.ietf-dane-ops] + Dukhovni, V. and W. Hardaker, "DANE TLSA implementation + and operational guidance", draft-ietf-dane-ops-00 (work in + progress), October 2013. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over + Transport Layer Security", RFC 3207, February 2002. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, May 2008. + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 32] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + + [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: + Extension Definitions", RFC 6066, January 2011. + + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and + Verification of Domain-Based Application Service Identity + within Internet Public Key Infrastructure Using X.509 + (PKIX) Certificates in the Context of Transport Layer + Security (TLS)", RFC 6125, March 2011. + + [RFC6186] Daboo, C., "Use of SRV Records for Locating Email + Submission/Access Services", RFC 6186, March 2011. + + [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the + DNS", RFC 6672, June 2012. + + [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication + of Named Entities (DANE) Transport Layer Security (TLS) + Protocol: TLSA", RFC 6698, August 2012. + +13.2. Informative References + + [I-D.ietf-dane-registry-acronyms] + Gudmundsson, O., "Adding acronyms to simplify DANE + conversations", draft-ietf-dane-registry-acronyms-01 (work + in progress), October 2013. + + [I-D.ietf-dane-srv] + Finch, T., "Using DNS-Based Authentication of Named + Entities (DANE) TLSA records with SRV and MX records.", + draft-ietf-dane-srv-02 (work in progress), February 2013. + + [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July + 2009. + + [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", + STD 72, RFC 6409, November 2011. + +Authors' Addresses + + Viktor Dukhovni + Two Sigma + + Email: ietf-dane@dukhovni.org + + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 33] + +Internet-Draft SMTP security via opportunistic DANE TLS May 2014 + + + Wes Hardaker + Parsons + P.O. Box 382 + Davis, CA 95617 + US + + Email: ietf@hardakers.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dukhovni & Hardaker Expires November 26, 2014 [Page 34] |