1 Internet Engineering Task Force (IETF)                       V. Dukhovni   
    2 Request for Comments: 7672                                     Two Sigma   
    3 Category: Standards Track                                    W. Hardaker   
    4 ISSN: 2070-1721                                                  Parsons   
    5                                                             October 2015   
    8    SMTP Security via Opportunistic DNS-Based Authentication of Named       
    9              Entities (DANE) Transport Layer Security (TLS)                
   11 Abstract                                                                   
   13    This memo describes a downgrade-resistant protocol for SMTP transport   
   14    security between Message Transfer Agents (MTAs), based on the DNS-      
   15    Based Authentication of Named Entities (DANE) TLSA DNS record.          
   16    Adoption of this protocol enables an incremental transition of the      
   17    Internet email backbone to one using encrypted and authenticated        
   18    Transport Layer Security (TLS).                                         
   20 Status of This Memo                                                        
   22    This is an Internet Standards Track document.                           
   24    This document is a product of the Internet Engineering Task Force       
   25    (IETF).  It represents the consensus of the IETF community.  It has     
   26    received public review and has been approved for publication by the     
   27    Internet Engineering Steering Group (IESG).  Further information on     
   28    Internet Standards is available in Section 2 of RFC 5741.               
   30    Information about the current status of this document, any errata,      
   31    and how to provide feedback on it may be obtained at                    
   32    http://www.rfc-editor.org/info/rfc7672.                                 
   34 Copyright Notice                                                           
   36    Copyright (c) 2015 IETF Trust and the persons identified as the         
   37    document authors.  All rights reserved.                                 
   39    This document is subject to BCP 78 and the IETF Trust's Legal           
   40    Provisions Relating to IETF Documents                                   
   41    (http://trustee.ietf.org/license-info) in effect on the date of         
   42    publication of this document.  Please review these documents            
   43    carefully, as they describe your rights and restrictions with respect   
   44    to this document.  Code Components extracted from this document must    
   45    include Simplified BSD License text as described in Section 4.e of      
   46    the Trust Legal Provisions and are provided without warranty as         
   47    described in the Simplified BSD License.                                
   52 Dukhovni & Hardaker          Standards Track                    [Page 1]   

   53 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
   56 Table of Contents                                                          
   58    1. Introduction ....................................................3   
   59       1.1. Terminology ................................................4   
   60       1.2. Background .................................................6   
   61       1.3. SMTP Channel Security ......................................6   
   62            1.3.1. STARTTLS Downgrade Attack ...........................7   
   63            1.3.2. Insecure Server Name without DNSSEC .................7   
   64            1.3.3. Sender Policy Does Not Scale ........................8   
   65            1.3.4. Too Many Certification Authorities ..................9   
   66    2. Identifying Applicable TLSA Records .............................9   
   67       2.1. DNS Considerations .........................................9   
   68            2.1.1. DNS Errors, "Bogus" Responses, and                       
   69                   "Indeterminate" Responses ...........................9   
   70            2.1.2. DNS Error Handling .................................11   
   71            2.1.3. Stub Resolver Considerations .......................12   
   72       2.2. TLS Discovery .............................................13   
   73            2.2.1. MX Resolution ......................................14   
   74            2.2.2. Non-MX Destinations ................................16   
   75            2.2.3. TLSA Record Lookup .................................18   
   76    3. DANE Authentication ............................................20   
   77       3.1. TLSA Certificate Usages ...................................20   
   78            3.1.1. Certificate Usage DANE-EE(3) .......................21   
   79            3.1.2. Certificate Usage DANE-TA(2) .......................22   
   80            3.1.3. Certificate Usages PKIX-TA(0) and PKIX-EE(1) .......23   
   81       3.2. Certificate Matching ......................................24   
   82            3.2.1. DANE-EE(3) Name Checks .............................24   
   83            3.2.2. DANE-TA(2) Name Checks .............................24   
   84            3.2.3. Reference Identifier Matching ......................25   
   85    4. Server Key Management ..........................................26   
   86    5. Digest Algorithm Agility .......................................27   
   87    6. Mandatory TLS Security .........................................27   
   88    7. Note on DANE for Message User Agents ...........................28   
   89    8. Interoperability Considerations ................................28   
   90       8.1. SNI Support ...............................................28   
   91       8.2. Anonymous TLS Cipher Suites ...............................29   
   92    9. Operational Considerations .....................................29   
   93       9.1. Client Operational Considerations .........................29   
   94       9.2. Publisher Operational Considerations ......................30   
   95    10. Security Considerations .......................................30   
   96    11. References ....................................................31   
   97       11.1. Normative References .....................................31   
   98       11.2. Informative References ...................................33   
   99    Acknowledgements ..................................................34   
  100    Authors' Addresses ................................................34   
  107 Dukhovni & Hardaker          Standards Track                    [Page 2]   

  108 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  111 1.  Introduction                                                           
  113    This memo specifies a new connection security model for Message         
  114    Transfer Agents (MTAs).  This model is motivated by key features of     
  115    inter-domain SMTP delivery, principally, the fact that the              
  116    destination server is selected indirectly via DNS Mail Exchange (MX)    
  117    records and that neither email addresses nor MX hostnames signal a      
  118    requirement for either secure or cleartext transport.  Therefore,       
  119    aside from a few manually configured exceptions, SMTP transport         
  120    security is, by necessity, opportunistic (for a definition of           
  121    "Opportunistic Security", see [RFC7435]).                               
  123    This specification uses the presence of DANE TLSA records to securely   
  124    signal TLS support and to publish the means by which SMTP clients can   
  125    successfully authenticate legitimate SMTP servers.  This becomes        
  126    "opportunistic DANE TLS" and is resistant to downgrade and              
  127    man-in-the-middle (MITM) attacks.  It enables an incremental            
  128    transition of the email backbone to authenticated TLS delivery, with    
  129    increased global protection as adoption increases.                      
  131    With opportunistic DANE TLS, traffic from SMTP clients to domains       
  132    that publish "usable" DANE TLSA records in accordance with this memo    
  133    is authenticated and encrypted.  Traffic from legacy clients or to      
  134    domains that do not publish TLSA records will continue to be sent in    
  135    the same manner as before, via manually configured security,            
  136    (pre-DANE) opportunistic TLS, or just cleartext SMTP.                   
  138    Problems with the existing use of TLS in MTA-to-MTA SMTP that           
  139    motivate this specification are described in Section 1.3.  The          
  140    specification itself follows, in Sections 2 and 3, which describe,      
  141    respectively, how to locate and use DANE TLSA records with SMTP.  In    
  142    Section 6, we discuss the application of DANE TLS to destinations for   
  143    which channel integrity and confidentiality are mandatory.  In          
  144    Section 7, we briefly comment on the potential applicability of this    
  145    specification to Message User Agents.                                   
  162 Dukhovni & Hardaker          Standards Track                    [Page 3]   

  163 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  166 1.1.  Terminology                                                          
  168    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  170    "OPTIONAL" in this document are to be interpreted as described in       
  171    [RFC2119].                                                              
  173    The following terms or concepts are used throughout this document:      
  175    Man-in-the-middle (MITM) attack:  Active modification of network        
  176       traffic by an adversary able to thereby compromise the               
  177       confidentiality or integrity of the data.                            
  179    Downgrade attack:  (From [RFC4949].)  A type of MITM attack in which    
  180       the attacker can cause two parties, at the time they negotiate a     
  181       security association, to agree on a lower level of protection than   
  182       the highest level that could have been supported by both of them.    
  184    Downgrade-resistant:  A protocol is "downgrade-resistant" if it         
  185       employs effective countermeasures against downgrade attacks.         
  187    "Secure", "bogus", "insecure", "indeterminate":  DNSSEC validation      
  188       results, as defined in Section 4.3 of [RFC4035].                     
  190    Validating security-aware stub resolver and non-validating              
  191    security-aware stub resolver:                                           
  192       Capabilities of the stub resolver in use, as defined in [RFC4033];   
  193       note that this specification requires the use of a security-aware    
  194       stub resolver.                                                       
  196    (Pre-DANE) opportunistic TLS:  Best-effort use of TLS that is           
  197       generally vulnerable to DNS forgery and STARTTLS downgrade           
  198       attacks.  When a TLS-encrypted communication channel is not          
  199       available, message transmission takes place in the clear.  MX        
  200       record indirection generally precludes authentication even when      
  201       TLS is available.                                                    
  203    Opportunistic DANE TLS:  Best-effort use of TLS that is resistant to    
  204       downgrade attacks for destinations with DNSSEC-validated TLSA        
  205       records.  When opportunistic DANE TLS is determined to be            
  206       unavailable, clients should fall back to pre-DANE opportunistic      
  207       TLS.  Opportunistic DANE TLS requires support for DNSSEC, DANE,      
  208       and STARTTLS on the client side, and STARTTLS plus a DNSSEC          
  209       published TLSA record on the server side.                            
  217 Dukhovni & Hardaker          Standards Track                    [Page 4]   

  218 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  221    Reference identifier:  (Special case of [RFC6125] definition.)  One     
  222       of the domain names associated by the SMTP client with the           
  223       destination SMTP server for performing name checks on the server     
  224       certificate.  When name checks are applicable, at least one of the   
  225       reference identifiers MUST match an [RFC6125] DNS-ID (or, if none    
  226       are present, the [RFC6125] CN-ID) of the server certificate (see     
  227       Section 3.2.3).                                                      
  229    MX hostname:  The RRDATA of an MX record consists of a 16 bit           
  230       preference followed by a Mail Exchange domain name (see [RFC1035],   
  231       Section 3.3.9).  We will use the term "MX hostname" to refer to      
  232       the latter, that is, the DNS domain name found after the             
  233       preference value in an MX record.  Thus, an "MX hostname" is         
  234       specifically a reference to a DNS domain name rather than any host   
  235       that bears that name.                                                
  237    Delayed delivery:  Email delivery is a multi-hop store-and-forward      
  238       process.  When an MTA is unable to forward a message that may        
  239       become deliverable later, the message is queued and delivery is      
  240       retried periodically.  Some MTAs may be configured with a fallback   
  241       next-hop destination that handles messages that the MTA would        
  242       otherwise queue and retry.  When a fallback next-hop destination     
  243       is configured, messages that would otherwise have to be delayed      
  244       may be sent to the fallback next-hop destination instead.  The       
  245       fallback destination may itself be subject to opportunistic or       
  246       mandatory DANE TLS (Section 6) as though it were the original        
  247       message destination.                                                 
  249    Original next-hop destination:  The logical destination for mail        
  250       delivery.  By default, this is the domain portion of the recipient   
  251       address, but MTAs may be configured to forward mail for some or      
  252       all recipients via designated relays.  The original next-hop         
  253       destination is, respectively, either the recipient domain or the     
  254       associated configured relay.                                         
  256    MTA:  Message Transfer Agent ([RFC5598], Section 4.3.2).                
  258    MSA:  Message Submission Agent ([RFC5598], Section 4.3.1).              
  260    MUA:  Message User Agent ([RFC5598], Section 4.2.1).                    
  262    RR:  A DNS resource record as defined in [RFC1034], Section 3.6.        
  264    RRset:  An RRset ([RFC2181], Section 5) is a group of DNS resource      
  265       records that share the same label, class, and type.                  
  272 Dukhovni & Hardaker          Standards Track                    [Page 5]   

  273 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  276 1.2.  Background                                                           
  278    The Domain Name System Security Extensions (DNSSEC) add data origin     
  279    authentication, data integrity, and data nonexistence proofs to the     
  280    Domain Name System (DNS).  DNSSEC is defined in [RFC4033], [RFC4034],   
  281    and [RFC4035].                                                          
  283    As described in the introduction of [RFC6698], TLS authentication via   
  284    the existing public Certification Authority (CA) PKI suffers from an    
  285    overabundance of trusted parties capable of issuing certificates for    
  286    any domain of their choice.  DANE leverages the DNSSEC infrastructure   
  287    to publish public keys and certificates for use with the Transport      
  288    Layer Security (TLS) [RFC5246] protocol via the "TLSA" DNS record       
  289    type.  With DNSSEC, each domain can only vouch for the keys of its      
  290    delegated sub-domains.                                                  
  292    The TLS protocol enables secure TCP communication.  In the context of   
  293    this memo, channel security is assumed to be provided by TLS.  Used     
  294    without authentication, TLS provides only privacy protection against    
  295    eavesdropping attacks.  Otherwise, TLS also provides data origin        
  296    authentication to guard against MITM attacks.                           
  298 1.3.  SMTP Channel Security                                                
  300    With HTTPS, TLS employs X.509 certificates [RFC5280] issued by one of   
  301    the many CAs bundled with popular web browsers to allow users to        
  302    authenticate their "secure" websites.  Before we specify a new DANE     
  303    TLS security model for SMTP, we will explain why a new security model   
  304    is needed.  In the process, we will explain why the familiar HTTPS      
  305    security model is inadequate to protect inter-domain SMTP traffic.      
  307    The subsections below outline four key problems with applying           
  308    traditional Web PKI [RFC7435] to SMTP; these problems are addressed     
  309    by this specification.  Since an SMTP channel security policy is not    
  310    explicitly specified in either the recipient address or the MX          
  311    record, a new signaling mechanism is required to indicate when          
  312    channel security is possible and should be used.  The publication of    
  313    TLSA records allows server operators to securely signal to SMTP         
  314    clients that TLS is available and should be used.  DANE TLSA makes it   
  315    possible to simultaneously discover which destination domains support   
  316    secure delivery via TLS and how to verify the authenticity of the       
  317    associated SMTP services, providing a path forward to ubiquitous SMTP   
  318    channel security.                                                       
  327 Dukhovni & Hardaker          Standards Track                    [Page 6]   

  328 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  331 1.3.1.  STARTTLS Downgrade Attack                                          
  333    SMTP [RFC5321] is a single-hop protocol in a multi-hop store-and-       
  334    forward email delivery process.  An SMTP envelope recipient address     
  335    does not correspond to a specific transport-layer endpoint address;     
  336    rather, at each relay hop, the transport-layer endpoint is the          
  337    next-hop relay, while the envelope recipient address typically          
  338    remains the same.  Unlike HTTP and its corresponding secured version,   
  339    HTTPS, where the use of TLS is signaled via the URI scheme, email       
  340    recipient addresses do not directly signal transport security policy.   
  341    Indeed, no such signaling could work well with SMTP, since TLS          
  342    encryption of SMTP protects email traffic on a hop-by-hop basis while   
  343    email addresses could only express end-to-end policy.                   
  345    With no mechanism available to signal transport security policy, SMTP   
  346    relays employ a best-effort "opportunistic" security model for TLS.     
  347    A single SMTP server TCP listening endpoint can serve both TLS and      
  348    non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS     
  349    command [RFC3207].  The server signals TLS support to the client over   
  350    a cleartext SMTP connection, and, if the client also supports TLS, it   
  351    may negotiate a TLS-encrypted channel to use for email transmission.    
  352    The server's indication of TLS support can be easily suppressed by an   
  353    MITM attacker.  Thus, pre-DANE SMTP TLS security can be subverted by    
  354    simply downgrading a connection to cleartext.  No TLS security          
  355    feature can prevent this.  The attacker can simply disable TLS.         
  357 1.3.2.  Insecure Server Name without DNSSEC                                
  359    With SMTP, DNS MX records abstract the next-hop transport endpoint      
  360    and allow administrators to specify a set of target servers to which    
  361    SMTP traffic should be directed for a given domain.                     
  363    A TLS client is vulnerable to MITM attacks unless it verifies that      
  364    the server's certificate binds the public key to a name that matches    
  365    one of the client's reference identifiers.  A natural choice of         
  366    reference identifier is the server's domain name.  However, with        
  367    SMTP, server names are not directly encoded in the recipient address;   
  368    instead, they are obtained indirectly via MX records.  Without          
  369    DNSSEC, the MX lookup is vulnerable to MITM and DNS cache poisoning     
  370    attacks.  Active attackers can forge DNS replies with fake MX records   
  371    and can redirect email to servers with names of their choice.           
  372    Therefore, secure verification of SMTP TLS certificates matching the    
  373    server name is not possible without DNSSEC.                             
  382 Dukhovni & Hardaker          Standards Track                    [Page 7]   

  383 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  386    One might try to harden TLS for SMTP against DNS attacks by using the   
  387    envelope recipient domain as a reference identifier and by requiring    
  388    each SMTP server to possess a trusted certificate for the envelope      
  389    recipient domain rather than the MX hostname.  Unfortunately, this is   
  390    impractical, as email for many domains is handled by third parties      
  391    that are not in a position to obtain certificates for all the domains   
  392    they serve.  Deployment of the Server Name Indication (SNI) extension   
  393    to TLS (see Section 3 of [RFC6066]) is no panacea, since SNI key        
  394    management is operationally challenging except when the email service   
  395    provider is also the domain's registrar and its certificate issuer;     
  396    this is rarely the case for email.                                      
  398    Since the recipient domain name cannot be used as the SMTP server       
  399    reference identifier, and neither can the MX hostname without DNSSEC,   
  400    large-scale deployment of authenticated TLS for SMTP requires that      
  401    the DNS be secure.                                                      
  403    Since SMTP security depends critically on DNSSEC, it is important to    
  404    point out that SMTP with DANE is consequently the most conservative     
  405    possible trust model.  It trusts only what must be trusted and no       
  406    more.  Adding any other trusted actors to the mix can only reduce       
  407    SMTP security.  A sender may choose to further harden DNSSEC for        
  408    selected high-value receiving domains by configuring explicit trust     
  409    anchors for those domains instead of relying on the chain of trust      
  410    from the root domain.  However, detailed discussion of DNSSEC           
  411    security practices is out of scope for this document.                   
  413 1.3.3.  Sender Policy Does Not Scale                                       
  415    Sending systems are in some cases explicitly configured to use TLS      
  416    for mail sent to selected peer domains, but this requires configuring   
  417    sending MTAs with appropriate subject names or certificate content      
  418    digests from their peer domains.  Due to the resulting administrative   
  419    burden, such statically configured SMTP secure channels are used        
  420    rarely (generally only between domains that make bilateral              
  421    arrangements with their business partners).  Internet email, on the     
  422    other hand, requires regularly contacting new domains for which         
  423    security configurations cannot be established in advance.               
  425    The abstraction of the SMTP transport endpoint via DNS MX records,      
  426    often across organizational boundaries, limits the use of public CA     
  427    PKI with SMTP to a small set of sender-configured peer domains.  With   
  428    little opportunity to use TLS authentication, sending MTAs are rarely   
  429    configured with a comprehensive list of trusted CAs.  SMTP services     
  430    that support STARTTLS often deploy X.509 certificates that are          
  431    self-signed or issued by a private CA.                                  
  437 Dukhovni & Hardaker          Standards Track                    [Page 8]   

  438 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  441 1.3.4.  Too Many Certification Authorities                                 
  443    Even if it were generally possible to determine a secure server name,   
  444    the SMTP client would still need to verify that the server's            
  445    certificate chain is issued by a trusted CA (a trust anchor).  MTAs     
  446    are not interactive applications where a human operator can make a      
  447    decision (wisely or otherwise) to selectively disable TLS security      
  448    policy when certificate chain verification fails.  With no user to      
  449    "click OK", the MTA's list of public CA trust anchors would need to     
  450    be comprehensive in order to avoid bouncing mail addressed to sites     
  451    that employ unknown CAs.                                                
  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.                                                       
  459 2.  Identifying Applicable TLSA Records                                    
  461 2.1.  DNS Considerations                                                   
  463 2.1.1.  DNS Errors, "Bogus" Responses, and "Indeterminate" Responses       
  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.                                                 
  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:       
  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.                                                  
  484    Note that the "indeterminate" security status has a conflicting         
  485    definition in Section 5 of [RFC4033]:                                   
  487       There is no trust anchor that would indicate that a specific         
  488       portion of the tree is secure.                                       
  492 Dukhovni & Hardaker          Standards Track                    [Page 9]   

  493 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  496    In this document, the term "indeterminate" will be used exclusively     
  497    in the [RFC4035] sense.  Therefore, obtaining "indeterminate" lookup    
  498    results is a (transient) failure condition, namely, the inability to    

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.

  499    locate the relevant DNS records.  DNS records that would be             
  500    classified "indeterminate" in the sense of [RFC4035] are simply         
  501    classified as "insecure".                                               
  503    We do not need to distinguish between zones that lack a suitable        
  504    ancestor trust anchor, and delegations (ultimately) from a trust        
  505    anchor that designate a child zone as being "insecure".  All            
  506    "insecure" RRsets MUST be handled identically: in either case,          
  507    non-validated data for the query domain is all that is and can be       
  508    available, and authentication using the data is impossible.  As the     
  509    DNS root zone has been signed, we expect that validating resolvers      
  510    used by Internet-facing MTAs will be configured with trust anchor       
  511    data for the root zone and that therefore domains with no ancestor      
  512    trust anchor will not be possible in most deployments.                  
  514    As noted in Section 4.3 of [RFC4035], a security-aware DNS resolver     
  515    MUST be able to determine whether a given non-error DNS response is     
  516    "secure", "insecure", "bogus", or "indeterminate".  It is expected      
  517    that most security-aware stub resolvers will not signal an              
  518    "indeterminate" security status (in the sense of [RFC4035]) to the      
  519    application and will instead signal a "bogus" or error result.  If a    
  520    resolver does signal an [RFC4035] "indeterminate" security status,      
  521    this MUST be treated by the SMTP client as though a "bogus" or error    
  522    result had been returned.                                               
  524    An MTA using a non-validating security-aware stub resolver MAY use      
  525    the stub resolver's ability, if available, to signal DNSSEC             
  526    validation status based on information the stub resolver has learned    
  527    from an upstream validating recursive resolver.  Security-oblivious     
  528    stub resolvers [RFC4033] MUST NOT be used.  In accordance with          
  529    Section 4.9.3 of [RFC4035]:                                             
  531       ... a security-aware stub resolver MUST NOT place any reliance on    
  532       signature validation allegedly performed on its behalf, except       
  533       when the security-aware stub resolver obtained the data in           
  534       question from a trusted security-aware recursive name server via a   
  535       secure channel.                                                      
  537    To avoid much repetition in the text below, we will pause to explain    
  538    the handling of "bogus" or "indeterminate" DNSSEC query responses.      
  539    These are not necessarily the result of a malicious actor; they can,    
  540    for example, occur when network packets are corrupted or lost in        
  541    transit.  Therefore, "bogus" or "indeterminate" replies are equated     
  542    in this memo with lookup failure.                                       
  547 Dukhovni & Hardaker          Standards Track                   [Page 10]   

  548 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  551    There is an important non-failure condition we need to highlight in     
  552    addition to the obvious case of the DNS client obtaining a non-empty    
  553    "secure" or "insecure" RRset of the requested type.  Namely, it is      
  554    not an error when either "secure" or "insecure" nonexistence is         
  555    determined for the requested data.  When a DNSSEC response with a       
  556    validation status that is either "secure" or "insecure" reports         
  557    either no records of the requested type or nonexistence of the query    
  558    domain, the response is not a DNS error condition.  The DNS client      
  559    has not been left without an answer; it has learned that records of     
  560    the requested type do not exist.                                        
  562    Security-aware stub resolvers will, of course, also signal DNS lookup   
  563    errors in other cases, for example, when processing a "SERVFAIL"        
  564    [RFC2136] response code (RCODE) [RFC1035], which will not have an       
  565    associated DNSSEC status.  All lookup errors are treated the same way   
  566    by this specification, regardless of whether they are from a "bogus"    
  567    or "indeterminate" DNSSEC status or from a more generic DNS error:      
  568    the information that was requested cannot be obtained by the            
  569    security-aware resolver at this time.  Thus, a lookup error is either   
  570    a failure to obtain the relevant RRset if it exists or a failure to     
  571    determine that no such RRset exists when it does not.                   
  573    In contrast to a "bogus" response or an "indeterminate" response, an    
  574    "insecure" DNSSEC response is not an error; rather, as explained        
  575    above, it indicates that the target DNS zone is either delegated as     
  576    an "insecure" child of a "secure" parent zone or not a descendant of    
  577    any of the configured DNSSEC trust anchors in use by the SMTP client.   
  578    "Insecure" results will leave the SMTP client with degraded channel     
  579    security but do not stand in the way of message delivery.  See          
  580    Section 2.2 for further details.                                        
  582 2.1.2.  DNS Error Handling                                                 
  584    When a DNS lookup failure (an error, "bogus", or "indeterminate", as    
  585    defined above) prevents an SMTP client from determining which SMTP      
  586    server or servers it should connect to, message delivery MUST be        
  587    delayed.  This naturally includes, for example, the case when a         
  588    "bogus" or "indeterminate" response is encountered during MX            
  589    resolution.  When multiple MX hostnames are obtained from a             
  590    successful MX lookup but a later DNS lookup failure prevents network    
  591    address resolution for a given MX hostname, delivery may proceed via    
  592    any remaining MX hosts.                                                 
  594    When a particular SMTP server is securely identified as the delivery    
  595    destination, a set of DNS lookups (Section 2.2) MUST be performed to    
  596    locate any related TLSA records.  If any DNS queries used to locate     
  597    TLSA records fail (due to "bogus" or "indeterminate" records,           
  598    timeouts, malformed replies, SERVFAIL responses, etc.), then the SMTP   
  602 Dukhovni & Hardaker          Standards Track                   [Page 11]   

  603 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  606    client MUST treat that server as unreachable and MUST NOT deliver the   
  607    message via that server.  If no servers are reachable, delivery is      
  608    delayed.                                                                
  610    In the text that follows, we will only describe what happens when all   
  611    relevant DNS queries succeed.  If any DNS failure occurs, the SMTP      
  612    client MUST behave as described in this section, by "skipping" the      
  613    SMTP server or destination that is problematic.  Queries for            
  614    candidate TLSA records are explicitly part of "all relevant DNS         
  615    queries", and SMTP clients MUST NOT continue to connect to an SMTP      
  616    server or destination whose TLSA record lookup fails.                   
  618 2.1.3.  Stub Resolver Considerations                                       
  620    A note about DNAME aliases: a query for a domain name whose ancestor    
  621    domain is a DNAME alias returns the DNAME RR for the ancestor domain    
  622    along with a CNAME that maps the query domain to the corresponding      
  623    sub-domain of the target domain of the DNAME alias [RFC6672].           
  624    Therefore, whenever we speak of CNAME aliases, we implicitly allow      
  625    for the possibility that the alias in question is the result of an      
  626    ancestor domain DNAME record.  Consequently, no explicit support for    
  627    DNAME records is needed in SMTP software; it is sufficient to process   
  628    the resulting CNAME aliases.  DNAME records only require special        
  629    processing in the validating stub resolver library that checks the      
  630    integrity of the combined DNAME + CNAME reply.  When DNSSEC             
  631    validation is handled by a local caching resolver rather than the MTA   
  632    itself, even that part of the DNAME support logic is outside the MTA.   
  634    When a stub resolver returns a response containing a CNAME alias that   
  635    does not also contain the corresponding query results for the target    
  636    of the alias, the SMTP client will need to repeat the query at the      
  637    target of the alias and should do so recursively up to some             
  638    configured or implementation-dependent recursion limit.  If at any      
  639    stage of CNAME expansion an error is detected, the lookup of the        
  640    original requested records MUST be considered to have failed.           
  642    Whether a chain of CNAME records was returned in a single stub          
  643    resolver response or via explicit recursion by the SMTP client, if at   
  644    any stage of recursive expansion an "insecure" CNAME record is          
  645    encountered, then it and all subsequent results (in particular, the     
  646    final result) MUST be considered "insecure", regardless of whether or   
  647    not any earlier CNAME records leading to the "insecure" record were     
  648    "secure".                                                               
  650    Note that a security-aware non-validating stub resolver may return to   
  651    the SMTP client an "insecure" reply received from a validating          
  652    recursive resolver that contains a CNAME record along with additional   
  653    answers recursively obtained starting at the target of the CNAME.  In   
  657 Dukhovni & Hardaker          Standards Track                   [Page 12]   

  658 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  661    this case, the only possible conclusion is that some record in the      
  662    set of records returned is "insecure", and it is, in fact, possible     
  663    that the initial CNAME record and a subset of the subsequent records    
  664    are "secure".                                                           
  666    If the SMTP client needs to determine the security status of the DNS    
  667    zone containing the initial CNAME record, it will need to issue a       
  668    separate query of type "CNAME" that returns only the initial CNAME      
  669    record.  Specifically, as discussed in Section 2.2.2, when "insecure"   
  670    A or AAAA records are found for an SMTP server via a CNAME alias, the   
  671    SMTP client will need to perform an additional CNAME query in order     
  672    to determine whether or not the DNS zone in which the alias is          
  673    published is DNSSEC signed.                                             
  675 2.2.  TLS Discovery                                                        
  677    As noted previously (in Section 1.3.1), opportunistic TLS with SMTP     
  678    servers that advertise TLS support via STARTTLS is subject to an MITM   
  679    downgrade attack.  Also, some SMTP servers that are not, in fact, TLS   
  680    capable erroneously advertise STARTTLS by default, and clients need     
  681    to be prepared to retry cleartext delivery after STARTTLS fails.  In    
  682    contrast, DNSSEC-validated TLSA records MUST NOT be published for       
  683    servers that do not support TLS.  Clients can safely interpret their    
  684    presence as a commitment by the server operator to implement TLS and    
  685    STARTTLS.                                                               
  687    This memo defines four actions to be taken after the search for a       
  688    TLSA record returns "secure" usable results, "secure" unusable          
  689    results, "insecure" or no results, or an error signal.  The term        
  690    "usable" in this context is in the sense of Section 4.1 of [RFC6698].   
  691    Specifically, if the DNS lookup for a TLSA record returns:              
  693    A "secure" TLSA RRset with at least one usable record:  Any             
  694       connection to the MTA MUST employ TLS encryption and MUST            
  695       authenticate the SMTP server using the techniques discussed in the   
  696       rest of this document.  Failure to establish an authenticated TLS    
  697       connection MUST result in falling back to the next SMTP server or    
  698       delayed delivery.                                                    
  700    A "secure" non-empty TLSA RRset where all the records are unusable:     
  701       Any connection to the MTA MUST be made via TLS, but authentication   
  702       is not required.  Failure to establish an encrypted TLS connection   
  703       MUST result in falling back to the next SMTP server or delayed       
  704       delivery.                                                            
  712 Dukhovni & Hardaker          Standards Track                   [Page 13]   

  713 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  716    An "insecure" TLSA RRset or DNSSEC-authenticated denial of existence    
  717    of the TLSA records:                                                    
  718       A connection to the MTA SHOULD be made using (pre-DANE)              
  719       opportunistic TLS; this includes using cleartext delivery when the   
  720       remote SMTP server does not appear to support TLS.  The MTA MAY      
  721       retry in cleartext when delivery via TLS fails during the            
  722       handshake or even during data transfer.                              
  724    Any lookup error:  Lookup errors, including "bogus" and                 
  725       "indeterminate" as explained in Section 2.1.1, MUST result in        
  726       falling back to the next SMTP server or delayed delivery.            
  728    An SMTP client MAY be configured to mandate DANE-verified delivery      
  729    for some destinations.  With mandatory DANE TLS (Section 6), delivery   
  730    proceeds only when "secure" TLSA records are used to establish an       
  731    encrypted and authenticated TLS channel with the SMTP server.           
  733    When the original next-hop destination is an address literal rather     
  734    than a DNS domain, DANE TLS does not apply.  Delivery proceeds using    
  735    any relevant security policy configured by the MTA administrator.       
  736    Similarly, when an MX RRset incorrectly lists a network address in      
  737    lieu of an MX hostname, if an MTA chooses to connect to the network     
  738    address in the nonconformant MX record, DANE TLSA does not apply for    
  739    such a connection.                                                      
  741    In the subsections that follow, we explain how to locate the SMTP       
  742    servers and the associated TLSA records for a given next-hop            
  743    destination domain.  We also explain which name or names are to be      
  744    used in identity checks of the SMTP server certificate.                 
  746 2.2.1.  MX Resolution                                                      
  748    In this section, we consider next-hop domains that are subject to MX    
  749    resolution and have MX records.  The TLSA records and the associated    
  750    base domain are derived separately for each MX hostname that is used    
  751    to attempt message delivery.  DANE TLS can authenticate message         
  752    delivery to the intended next-hop domain only when the MX records are   
  753    obtained securely via a DNSSEC-validated lookup.                        
  755    MX records MUST be sorted by preference; an MX hostname with a worse    
  756    (numerically higher) MX preference that has TLSA records MUST NOT       
  757    preempt an MX hostname with a better (numerically lower) preference     
  758    that has no TLSA records.  In other words, prevention of delivery       
  759    loops by obeying MX preferences MUST take precedence over channel       
  760    security considerations.  Even with two equal-preference MX records,    
  761    an MTA is not obligated to choose the MX hostname that offers more      
  767 Dukhovni & Hardaker          Standards Track                   [Page 14]   

  768 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  771    security.  Domains that want secure inbound mail delivery need to       
  772    ensure that all their SMTP servers and MX records are configured        
  773    accordingly.                                                            
  775    In the language of [RFC5321], Section 5.1, the original next-hop        
  776    domain is the "initial name".  If the MX lookup of the initial name     
  777    results in a CNAME alias, the MTA replaces the initial name with the    
  778    resulting name and performs a new lookup with the new name.  MTAs       
  779    typically support recursion in CNAME expansion, so this replacement     
  780    is performed repeatedly (up to the MTA's recursion limit) until the     
  781    ultimate non-CNAME domain is found.                                     
  783    If the MX RRset (or any CNAME leading to it) is "insecure" (see         
  784    Section 2.1.1) and DANE TLS for the given destination is mandatory      
  785    (Section 6), delivery MUST be delayed.  If the MX RRset is "insecure"   
  786    and DANE TLS is not mandatory, the SMTP client is free to use           
  787    pre-DANE opportunistic TLS (possibly even cleartext).                   
  789    Since the protocol in this memo is an Opportunistic Security protocol   
  790    [RFC7435], the SMTP client MAY elect to use DANE TLS (as described in   
  791    Section 2.2.2 below), even with MX hosts obtained via an "insecure"     
  792    MX RRset.  For example, when a hosting provider has a signed DNS zone   
  793    and publishes TLSA records for its SMTP servers, hosted domains that    
  794    are not signed may still benefit from the provider's TLSA records.      
  795    Deliveries via the provider's SMTP servers will not be subject to       
  796    active attacks when sending SMTP clients elect to use the provider's    
  797    TLSA records (active attacks that tamper with the "insecure" MX RRset   
  798    are of course still possible in this case).                             
  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.                                               
  810    In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset    
  811    is not "insecure", then it is "secure", and the SMTP client MUST        
  812    treat each MX hostname as described in Section 2.2.2.  When, for a      
  813    given MX hostname, no TLSA records are found or only "insecure" TLSA    
  814    records are found, DANE TLSA is not applicable with the SMTP server     
  815    in question, and delivery proceeds to that host as with pre-DANE        
  816    opportunistic TLS.  To avoid downgrade attacks, any errors during       
  817    TLSA lookups MUST, as explained in Section 2.1.2, cause the SMTP        
  818    server in question to be treated as unreachable.                        
  822 Dukhovni & Hardaker          Standards Track                   [Page 15]   

  823 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  826 2.2.2.  Non-MX Destinations                                                
  828    This section describes the algorithm used to locate the TLSA records    
  829    and associated TLSA base domain for an input domain that is not         
  830    subject to MX resolution, that represents a hostname from a "secure"    
  831    MX RRset, or that lacks MX records.  Such domains include:              
  833    o  Any host that is configured by the sending MTA administrator as      
  834       the next-hop relay for some or all domains and that is not subject   
  835       to MX resolution.                                                    
  837    o  A domain that has MX records.  When a domain has MX records, we      
  838       treat each MX host listed in those MX records as though it were a    
  839       non-MX destination -- that is, in the same way as we would treat     
  840       an administrator-configured relay that handles mail for that         
  841       domain.  (Unlike administrator-specified relays, MTAs are not        
  842       required to support CNAME expansion of next-hop names found via MX   
  843       lookups.)                                                            
  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      
  847       its sole SMTP server name.                                           
  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.  These nameservers SHOULD provide          
  853    "insecure" negative replies that indicate the nonexistence of the       
  854    TLSA records, but instead they fail by not responding at all or by      
  855    responding with a DNS RCODE [RFC1035] other than NXDOMAIN, e.g.,        
  856    SERVFAIL or NOTIMP [RFC2136].                                           
  858    To avoid problems delivering mail to domains whose SMTP servers are     
  859    served by these problematic nameservers, the SMTP client MUST perform   
  860    any A and/or AAAA queries for the destination before attempting to      
  861    locate the associated TLSA records.  This lookup is needed in any       
  862    case to determine (1) whether or not the destination domain is          
  863    reachable and (2) the DNSSEC validation status of the chain of CNAME    
  864    queries required to reach the ultimate address records.                 
  866    If no address records are found, the destination is unreachable.  If    
  867    address records are found but the DNSSEC validation status of the       
  868    first query response is "insecure" (see Section 2.1.3), the SMTP        
  869    client SHOULD NOT proceed to search for any associated TLSA records.    
  870    In the case of these problematic domains, TLSA queries would lead to    
  871    DNS lookup errors and would cause messages to be consistently delayed   
  872    and ultimately returned to the sender.  We don't expect to find any     
  877 Dukhovni & Hardaker          Standards Track                   [Page 16]   

  878 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  881    "secure" TLSA records associated with a TLSA base domain that lies in   
  882    an unsigned DNS zone.  Therefore, skipping TLSA lookups in this case    
  883    will also reduce latency, with no detrimental impact on security.       
  885    If the A and/or AAAA lookup of the initial name yields a CNAME, we      
  886    replace it with the resulting name as if it were the initial name and   
  887    perform a lookup again using the new name.  This replacement is         
  888    performed recursively (up to the MTA's recursion limit).                
  890    We consider the following cases for handling a DNS response for an      
  891    A or AAAA DNS lookup:                                                   
  893    Not found:  When the DNS queries for A and/or AAAA records yield        
  894       neither a list of addresses nor a CNAME (or CNAME expansion is not   
  895       supported), the destination is unreachable.                          
  897    Non-CNAME:  The answer is not a CNAME alias.  If the address RRset is   
  898       "secure", TLSA lookups are performed as described in Section 2.2.3   
  899       with the initial name as the candidate TLSA base domain.  If no      
  900       "secure" TLSA records are found, DANE TLS is not applicable and      
  901       mail delivery proceeds with pre-DANE opportunistic TLS (which,       
  902       being best-effort, degrades to cleartext delivery when STARTTLS is   
  903       not available or the TLS handshake fails).                           
  905    Insecure CNAME:  The input domain is a CNAME alias, but the ultimate    
  906       network address RRset is "insecure" (see Section 2.1.1).  If the     
  907       initial CNAME response is also "insecure", DANE TLS does not         
  908       apply.  Otherwise, this case is treated just like the non-CNAME      
  909       case above, where a search is performed for a TLSA record with the   
  910       original input domain as the candidate TLSA base domain.             
  912    Secure CNAME:  The input domain is a CNAME alias, and the ultimate      
  913       network address RRset is "secure" (see Section 2.1.1).  Two          
  914       candidate TLSA base domains are tried: the fully CNAME-expanded      
  915       initial name and, failing that, the initial name itself.             
  917    In summary, if it is possible to securely obtain the full,              
  918    CNAME-expanded, DNSSEC-validated address records for the input          
  919    domain, then that name is the preferred TLSA base domain.  Otherwise,   
  920    the unexpanded input domain is the candidate TLSA base domain.  When    
  921    no "secure" TLSA records are found at either the CNAME-expanded or      
  922    unexpanded domain, then DANE TLS does not apply for mail delivery via   
  923    the input domain in question.  And, as always, errors, "bogus"          
  924    results, or "indeterminate" results for any query in the process MUST   
  925    result in delaying or abandoning delivery.                              
  932 Dukhovni & Hardaker          Standards Track                   [Page 17]   

  933 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  936 2.2.3.  TLSA Record Lookup                                                 
  938    When the SMTP server's hostname is not a CNAME or DNAME alias, the      
  939    list of associated candidate TLSA base domains (see below) consists     
  940    of just the server hostname.                                            
  942    When the hostname is an alias with a "secure" (at every stage) full     
  943    expansion, the list of candidate TLSA base domains (see below) is a     
  944    pair of domains: the fully expanded server hostname first, and the      
  945    unexpanded server hostname second.                                      
  947    Each candidate TLSA base domain (alias-expanded or original) is in      
  948    turn prefixed with service labels of the form "_<port>._tcp".  The      
  949    resulting domain name is used to issue a DNSSEC query with the query    
  950    type set to TLSA ([RFC6698], Section 7.1).                              
  952    The first of these candidate domains to yield a "secure" TLSA RRset     
  953    becomes the actual TLSA base domain.                                    
  955    For SMTP, the destination TCP port is typically 25, but this may be     
  956    different with custom routes specified by the MTA administrator, in     
  957    which case the SMTP client MUST use the appropriate number in the       
  958    "_<port>" prefix in place of "_25".  If, for example, the candidate     
  959    base domain is "mx.example.com" and the SMTP connection is to port      
  960    25, the TLSA RRset is obtained via a DNSSEC query of the form:          
  962       _25._tcp.mx.example.com. IN TLSA ?                                   
  964    The query response may be a CNAME or the actual TLSA RRset.  If the     
  965    response is a CNAME, the SMTP client (through the use of its            
  966    security-aware stub resolver) restarts the TLSA query at the target     
  967    domain, following CNAMEs as appropriate, and keeps track of whether     
  968    or not the entire chain is "secure".  If any "insecure" records are     
  969    encountered or the TLSA records don't exist, the next candidate TLSA    
  970    base domain is tried instead.                                           
  972    If the ultimate response is a "secure" TLSA RRset, then the candidate   
  973    TLSA base domain will be the actual TLSA base domain, and the TLSA      
  974    RRset will constitute the TLSA records for the destination.  If none    
  975    of the candidate TLSA base domains yield "secure" TLSA records, then    
  976    the SMTP client is free to use pre-DANE opportunistic TLS (possibly     
  977    even cleartext).                                                        
  979    TLSA record publishers may leverage CNAMEs to reference a single        
  980    authoritative TLSA RRset specifying a common CA or a common             
  981    end-entity certificate to be used with multiple TLS services.  Such     
  982    CNAME expansion does not change the SMTP client's notion of the TLSA    
  983    base domain; thus, when _25._tcp.mx.example.com is a CNAME, the base    
  987 Dukhovni & Hardaker          Standards Track                   [Page 18]   

  988 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
  991    domain remains mx.example.com, and this is still the reference          
  992    identifier used together with the next-hop domain in peer certificate   
  993    name checks.                                                            
  995    Note that shared end-entity certificate associations expose the         
  996    publishing domain to substitution attacks, where an MITM attacker can   
  997    reroute traffic to a different server that shares the same end-entity   
  998    certificate.  Such shared end-entity TLSA records SHOULD be avoided     
  999    unless the servers in question are functionally equivalent or employ    
 1000    mutually incompatible protocols (an active attacker gains nothing by    
 1001    diverting client traffic from one such server to another).              
 1003    A better example, employing a shared trust anchor rather than shared    
 1004    end-entity certificates, is illustrated by the DNSSEC-validated         
 1005    records below:                                                          
 1007       example.com.                IN MX 0 mx1.example.com.                 
 1008       example.com.                IN MX 0 mx2.example.com.                 
 1009       _25._tcp.mx1.example.com.   IN CNAME tlsa201._dane.example.com.      
 1010       _25._tcp.mx2.example.com.   IN CNAME tlsa201._dane.example.com.      
 1011       tlsa201._dane.example.com.  IN TLSA 2 0 1 e3b0c44298fc1c149a...      
 1013    The SMTP servers mx1.example.com and mx2.example.com will be expected   
 1014    to have certificates issued under a common trust anchor, but each MX    
 1015    hostname's TLSA base domain remains unchanged despite the above CNAME   
 1016    records.  Correspondingly, each SMTP server will be associated with a   
 1017    pair of reference identifiers consisting of its hostname plus the       
 1018    next-hop domain "example.com".                                          
 1020    If, during TLSA resolution (including possible CNAME indirection), at   
 1021    least one "secure" TLSA record is found (even if not usable because     
 1022    it is unsupported by the implementation or support is                   
 1023    administratively disabled), then the corresponding host has signaled    
 1024    its commitment to implement TLS.  The SMTP client MUST NOT deliver      
 1025    mail via the corresponding host unless a TLS session is negotiated      
 1026    via STARTTLS.  This is required to avoid MITM STARTTLS downgrade        
 1027    attacks.                                                                
 1029    As noted previously (in Section 2.2.2), when no "secure" TLSA records   
 1030    are found at the fully CNAME-expanded name, the original unexpanded     
 1031    name MUST be tried instead.  This supports customers of hosting         
 1032    providers where the provider's zone cannot be validated with DNSSEC     
 1033    but the customer has shared appropriate key material with the hosting   
 1034    provider to enable TLS via SNI.  Intermediate names that arise during   
 1035    CNAME expansion that are neither the original name nor the final name   
 1036    are never candidate TLSA base domains, even if "secure".                
 1042 Dukhovni & Hardaker          Standards Track                   [Page 19]   

 1043 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1046 3.  DANE Authentication                                                    
 1048    This section describes which TLSA records are applicable to SMTP        
 1049    opportunistic DANE TLS and how to apply such records to authenticate    
 1050    the SMTP server.  With opportunistic DANE TLS, both the TLS support     
 1051    implied by the presence of DANE TLSA records and the verification       
 1052    parameters necessary to authenticate the TLS peer are obtained          
 1053    together.  In contrast to protocols where channel security policy is    
 1054    set exclusively by the client, authentication via this protocol is      
 1055    expected to be less prone to connection failure caused by               
 1056    incompatible configuration of the client and server.                    
 1058 3.1.  TLSA Certificate Usages                                              
 1060    The DANE TLSA specification [RFC6698] defines multiple TLSA RR types    
 1061    via combinations of three numeric parameters.  The numeric values of    
 1062    these parameters were later given symbolic names in [RFC7218].  The     
 1063    rest of the TLSA record is the "certificate association data field",    
 1064    which specifies the full or digest value of a certificate or            
 1065    public key.                                                             
 1067    Since opportunistic DANE TLS will be used by non-interactive MTAs,      
 1068    with no user to "click OK" when authentication fails, reliability of    
 1069    peer authentication is paramount.  Server operators are advised to      
 1070    publish TLSA records that are least likely to fail authentication due   
 1071    to interoperability or operational problems.  Because DANE TLS relies   
 1072    on coordinated changes to DNS and SMTP server settings, the best        
 1073    choice of records to publish will depend on site-specific practices.    
 1075    The certificate usage element of a TLSA record plays a critical role    
 1076    in determining how the corresponding certificate association data       
 1077    field is used to authenticate a server's certificate chain.             
 1078    Sections 3.1.1 and 3.1.2 explain the process for certificate usages     
 1079    DANE-EE(3) and DANE-TA(2), respectively.  Section 3.1.3 briefly         
 1080    explains why certificate usages PKIX-TA(0) and PKIX-EE(1) are not       
 1081    applicable with opportunistic DANE TLS.                                 
 1083    In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1) SHA2-256(1)",   
 1084    with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records as a second          
 1085    choice, depending on site needs.  See Sections 3.1.1 and 3.1.2 for      
 1086    more details.  Other combinations of TLSA parameters either (1) are     
 1087    explicitly unsupported or (2) offer little to recommend them over       
 1088    these two.                                                              
 1097 Dukhovni & Hardaker          Standards Track                   [Page 20]   

 1098 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1101 3.1.1.  Certificate Usage DANE-EE(3)                                       
 1103    Authentication via certificate usage DANE-EE(3) TLSA records involves   
 1104    simply checking that the server's leaf certificate matches the TLSA     
 1105    record.  In particular, the binding of the server public key to its     
 1106    name is based entirely on the TLSA record association.  The server      
 1107    MUST be considered authenticated even if none of the names in the       
 1108    certificate match the client's reference identity for the server.       
 1110    The expiration date of the server certificate MUST be ignored: the      
 1111    validity period of the TLSA record key binding is determined by the     
 1112    validity interval of the TLSA record DNSSEC signature.                  
 1114    With DANE-EE(3), servers need not employ SNI (they may ignore the       
 1115    client's SNI message) even when the server is known under independent   
 1116    names that would otherwise require separate certificates.  It is        
 1117    instead sufficient for the TLSA RRsets for all the domains in           
 1118    question to match the server's default certificate.  Of course, with    
 1119    SMTP servers it is simpler still to publish the same MX hostname for    
 1120    all the hosted domains.                                                 
 1122    For domains where it is practical to make coordinated changes in DNS    
 1123    TLSA records during SMTP server key rotation, it is often best to       
 1124    publish end-entity DANE-EE(3) certificate associations.  DANE-EE(3)     
 1125    certificates don't suddenly stop working when leaf or intermediate      
 1126    certificates expire, nor do they fail when the server operator          
 1127    neglects to configure all the required issuer certificates in the       
 1128    server certificate chain.                                               
 1130    TLSA records published for SMTP servers SHOULD, in most cases, be       
 1131    "DANE-EE(3) SPKI(1) SHA2-256(1)" records.  Since all DANE               
 1132    implementations are required to support SHA2-256, this record type      
 1133    works for all clients and need not change across certificate renewals   
 1134    with the same key.                                                      
 1152 Dukhovni & Hardaker          Standards Track                   [Page 21]   

 1153 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1156 3.1.2.  Certificate Usage DANE-TA(2)                                       
 1158    Some domains may prefer to avoid the operational complexity of          
 1159    publishing unique TLSA RRs for each TLS service.  If the domain         
 1160    employs a common issuing CA to create certificates for multiple TLS     
 1161    services, it may be simpler to publish the issuing authority as a       
 1162    trust anchor (TA) for the certificate chains of all relevant            
 1163    services.  The TLSA query domain (TLSA base domain with port and        
 1164    protocol prefix labels) for each service issued by the same TA may      
 1165    then be set to a CNAME alias that points to a common TLSA RRset that    
 1166    matches the TA.  For example:                                           
 1168       example.com.                IN MX 0 mx1.example.com.                 
 1169       example.com.                IN MX 0 mx2.example.com.                 
 1170       _25._tcp.mx1.example.com.   IN CNAME tlsa201._dane.example.com.      
 1171       _25._tcp.mx2.example.com.   IN CNAME tlsa201._dane.example.com.      
 1172       tlsa201._dane.example.com.  IN TLSA 2 0 1 e3b0c44298fc1c14....       
 1174    With usage DANE-TA(2), the server certificates will need to have        
 1175    names that match one of the client's reference identifiers (see         
 1176    [RFC6125]).  The server MAY employ SNI to select the appropriate        
 1177    certificate to present to the client.                                   
 1179    SMTP servers that rely on certificate usage DANE-TA(2) TLSA records     
 1180    for TLS authentication MUST include the TA certificate as part of the   
 1181    certificate chain presented in the TLS handshake server certificate     
 1182    message even when it is a self-signed root certificate.  Many SMTP      
 1183    servers are not configured with a comprehensive list of trust           
 1184    anchors, nor are they expected to be at any point in the future.        
 1185    Some MTAs will ignore all locally trusted certificates when             
 1186    processing usage DANE-TA(2) TLSA records.  Thus, even when the TA       
 1187    happens to be a public CA known to the SMTP client, authentication is   
 1188    likely to fail unless the TA certificate is included in the TLS         
 1189    server certificate message.                                             
 1191    With some SMTP server software, it is not possible to configure the     
 1192    server to include self-signed (root) CA certificates in the server      
 1193    certificate chain.  Such servers either MUST publish DANE-TA(2)         
 1194    records for an intermediate certificate or MUST instead use             
 1195    DANE-EE(3) TLSA records.                                                
 1197    TLSA records with a matching type of Full(0) are discouraged.  While    
 1198    these potentially obviate the need to transmit the TA certificate in    
 1199    the TLS server certificate message, client implementations may not be   
 1200    able to augment the server certificate chain with the data obtained     
 1201    from DNS, especially when the TLSA record supplies a bare key           
 1202    (selector SPKI(1)).  Since the server will need to transmit the TA      
 1203    certificate in any case, server operators SHOULD publish TLSA records   
 1207 Dukhovni & Hardaker          Standards Track                   [Page 22]   

 1208 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1211    with a matching type other than Full(0) and avoid potential             
 1212    interoperability issues with large TLSA records containing full         
 1213    certificates or keys.                                                   
 1215    TLSA Publishers employing DANE-TA(2) records SHOULD publish records     
 1216    with a selector of Cert(0).  Such TLSA records are associated with      
 1217    the whole trust anchor certificate, not just with the trust anchor      
 1218    public key.  In particular, the SMTP client SHOULD then apply any       
 1219    relevant constraints from the trust anchor certificate, such as, for    
 1220    example, path length constraints.                                       
 1222    While a selector of SPKI(1) may also be employed, the resulting TLSA    
 1223    record will not specify the full trust anchor certificate content,      
 1224    and elements of the trust anchor certificate other than the public      
 1225    key become mutable.  This may, for example, allow a subsidiary CA to    
 1226    issue a chain that violates the trust anchor's path length or name      
 1227    constraints.                                                            
 1229 3.1.3.  Certificate Usages PKIX-TA(0) and PKIX-EE(1)                       
 1231    Note that this section applies to MTA-to-MTA SMTP, which is normally    
 1232    on port 25 -- that is, to servers that are the SMTP servers for one     
 1233    or more destination domains.  Other uses of SMTP, such as in            
 1234    MUA-to-MSA submission on ports 587 or 465, are out of scope for this    
 1235    document.  Where those other uses also employ TLS opportunistically     
 1236    and/or depend on DNSSEC as a result of DNS-based discovery of service   
 1237    location, the relevant specifications should, as appropriate, arrive    
 1238    at similar conclusions.                                                 
 1240    As noted in Sections 1.3.1 and 1.3.2, sending MTAs cannot, without      
 1241    relying on DNSSEC for "secure" MX records and DANE for STARTTLS         
 1242    support signaling, perform server identity verification or prevent      
 1243    STARTTLS downgrade attacks.  The use of PKIX CAs offers no added        
 1244    security, since an attacker capable of compromising DNSSEC is free to   
 1245    replace any PKIX-TA(0) or PKIX-EE(1) TLSA records with records          
 1246    bearing any convenient non-PKIX certificate usage.  Finally, as         
 1247    explained in Section 1.3.4, there is no list of trusted CAs agreed      
 1248    upon by all MTAs and no user to "click OK" when a server's CA is not    
 1249    trusted by a client.                                                    
 1251    Therefore, TLSA records for the port 25 SMTP service used by client     
 1252    MTAs SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) or   
 1253    PKIX-EE(1).  SMTP client MTAs cannot be expected to be configured       
 1254    with a suitably complete set of trusted public CAs.  Lacking a          
 1255    complete set of public CAs, MTA clients would not be able to verify     
 1256    the certificates of SMTP servers whose issuing root CAs are not         
 1257    trusted by the client.                                                  
 1262 Dukhovni & Hardaker          Standards Track                   [Page 23]   

 1263 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1266    Opportunistic DANE TLS needs to interoperate without bilateral          
 1267    coordination of security settings between client and server systems.    
 1268    Therefore, parameter choices that are fragile in the absence of         
 1269    bilateral coordination are unsupported.  Nothing is lost; since the     
 1270    PKIX certificate usages cannot aid SMTP TLS security, they can only     
 1271    impede SMTP TLS interoperability.                                       
 1273    SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0)    
 1274    or PKIX-EE(1) is undefined.  As with any other unsupported              
 1275    certificate usage, SMTP clients MAY treat such records as "unusable".   
 1277 3.2.  Certificate Matching                                                 
 1279    When at least one usable "secure" TLSA record is found, the SMTP        
 1280    client MUST use TLSA records to authenticate the SMTP server.           
 1281    Messages MUST NOT be delivered via the SMTP server if authentication    
 1282    fails; otherwise, the SMTP client is vulnerable to MITM attacks.        
 1284 3.2.1.  DANE-EE(3) Name Checks                                             
 1286    The SMTP client MUST NOT perform certificate name checks with           
 1287    certificate usage DANE-EE(3) (Section 3.1.1).                           
line-499 Matt McCutchen(Technical Erratum #5395) [Verified]
based on outdated version
   DNS records that would be
   classified "indeterminate" in the sense of [RFC4035] are simply
   classified as "insecure".
It should say:
   DNS records that would be
   classified "indeterminate" in the sense of [RFC40353] are simply
   classified as "insecure".
 1289 3.2.2.  DANE-TA(2) Name Checks                                             
 1291    To match a server via a TLSA record with certificate usage              
 1292    DANE-TA(2), the client MUST perform name checks to ensure that it has   
 1293    reached the correct server.  In all DANE-TA(2) cases, the SMTP client   
 1294    MUST employ the TLSA base domain as the primary reference identifier    
 1295    for matching the server certificate.                                    
 1297    TLSA records for MX hostnames:  If the TLSA base domain was obtained    
 1298       indirectly via a "secure" MX lookup (including any CNAME-expanded    
 1299       name of an MX hostname), then the original next-hop domain used in   
 1300       the MX lookup MUST be included as a second reference identifier.     
 1301       The CNAME-expanded original next-hop domain MUST be included as a    
 1302       third reference identifier if different from the original next-hop   
 1303       domain.  When the client MTA is employing DANE TLS security          
 1304       despite "insecure" MX redirection, the MX hostname is the only       
 1305       reference identifier.                                                
 1307    TLSA records for non-MX hostnames:  If MX records were not used         
 1308       (e.g., if none exist) and the TLSA base domain is the                
 1309       CNAME-expanded original next-hop domain, then the original           
 1310       next-hop domain MUST be included as a second reference identifier.   
 1317 Dukhovni & Hardaker          Standards Track                   [Page 24]   

 1318 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1321    Accepting certificates with the original next-hop domain in addition    
 1322    to the MX hostname allows a domain with multiple MX hostnames to        
 1323    field a single certificate bearing a single domain name (i.e., the      
 1324    email domain) across all the SMTP servers.  This also aids              
 1325    interoperability with pre-DANE SMTP clients that are configured to      
 1326    look for the email domain name in server certificates -- for example,   
 1327    with "secure" DNS records as shown below:                               
 1329       exchange.example.org.            IN CNAME mail.example.org.          
 1330       mail.example.org.                IN CNAME example.com.               
 1331       example.com.                     IN MX    10 mx10.example.com.       
 1332       example.com.                     IN MX    15 mx15.example.com.       
 1333       example.com.                     IN MX    20 mx20.example.com.       
 1334       ;                                                                    
 1335       mx10.example.com.                IN A                 
 1336       _25._tcp.mx10.example.com.       IN TLSA  2 0 1 ...                  
 1337       ;                                                                    
 1338       mx15.example.com.                IN CNAME mxbackup.example.com.      
 1339       mxbackup.example.com.            IN A                 
 1340       ; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)                
 1341       _25._tcp.mx15.example.com.       IN TLSA  2 0 1 ...                  
 1342       ;                                                                    
 1343       mx20.example.com.                IN CNAME mxbackup.example.net.      
 1344       mxbackup.example.net.            IN A              
 1345       _25._tcp.mxbackup.example.net.   IN TLSA  2 0 1 ...                  
 1347    Certificate name checks for delivery of mail to exchange.example.org    
 1348    via any of the associated SMTP servers MUST accept at least the names   
 1349    "exchange.example.org" and "example.com", which are, respectively,      
 1350    the original and fully expanded next-hop domain.  When the SMTP         
 1351    server is mx10.example.com, name checks MUST accept the TLSA base       
 1352    domain "mx10.example.com".  If, despite the fact that MX hostnames      
 1353    are required to not be aliases, the MTA supports delivery via           
 1354    "mx15.example.com" or "mx20.example.com", then name checks MUST         
 1355    accept the respective TLSA base domains "mx15.example.com" and          
 1356    "mxbackup.example.net".                                                 
 1358 3.2.3.  Reference Identifier Matching                                      
 1360    When name checks are applicable (certificate usage DANE-TA(2)), if      
 1361    the server certificate contains a Subject Alternative Name extension    
 1362    [RFC5280] with at least one DNS-ID [RFC6125], then only the DNS-IDs     
 1363    are matched against the client's reference identifiers.  The CN-ID      
 1364    [RFC6125] is only considered when no DNS-IDs are present.  The server   
 1365    certificate is considered matched when one of its presented             
 1366    identifiers [RFC5280] matches any of the client's reference             
 1367    identifiers.                                                            
 1372 Dukhovni & Hardaker          Standards Track                   [Page 25]   

 1373 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1376    Wildcards are valid in either DNS-IDs or the CN-ID when applicable.     
 1377    The wildcard character must be the entire first label of the DNS-ID     
 1378    or CN-ID.  Thus, "*.example.com" is valid, while "smtp*.example.com"    
 1379    and "*smtp.example.com" are not.  SMTP clients MUST support wildcards   
 1380    that match the first label of the reference identifier, with the        
 1381    remaining labels matching verbatim.  For example, the DNS-ID            
 1382    "*.example.com" matches the reference identifier "mx1.example.com".     
 1383    SMTP clients MAY, subject to local policy, allow wildcards to match     
 1384    multiple reference identifier labels, but servers cannot expect broad   
 1385    support for such a policy.  Therefore, any wildcards in server          
 1386    certificates SHOULD match exactly one label in either the TLSA base     
 1387    domain or the next-hop domain.                                          
 1389 4.  Server Key Management                                                  
 1391    Two TLSA records MUST be published before employing a new EE or TA      
 1392    public key or certificate: one matching the currently deployed key      
 1393    and the other matching the new key scheduled to replace it.  Once       
 1394    sufficient time has elapsed for all DNS caches to expire the previous   
 1395    TLSA RRset and related signature RRsets, servers may be configured to   
 1396    use the new EE private key and associated public key certificate or     
 1397    may employ certificates signed by the new trust anchor.                 
 1399    Once the new public key or certificate is in use, the TLSA RR that      
 1400    matches the retired key can be removed from DNS, leaving only RRs       
 1401    that match keys or certificates in active use.                          
 1403    As described in Section 3.1.2, when server certificates are validated   
 1404    via a DANE-TA(2) trust anchor and CNAME records are employed to store   
 1405    the TA association data at a single location, the responsibility of     
 1406    updating the TLSA RRset shifts to the operator of the trust anchor.     
 1407    Before a new trust anchor is used to sign any new server                
 1408    certificates, its certificate (digest) is added to the relevant TLSA    
 1409    RRset.  After enough time elapses for the original TLSA RRset to age    
 1410    out of DNS caches, the new trust anchor can start issuing new server    
 1411    certificates.  Once all certificates issued under the previous trust    
 1412    anchor have expired, its associated RRs can be removed from the TLSA    
 1413    RRset.                                                                  
 1415    In the DANE-TA(2) key management model, server operators do not         
 1416    generally need to update DNS TLSA records after initially creating a    
 1417    CNAME record that references the centrally operated DANE-TA(2) RRset.   
 1418    If a particular server's key is compromised, its TLSA CNAME SHOULD be   
 1419    replaced with a DANE-EE(3) association until the certificate for the    
 1420    compromised key expires, at which point it can return to using a        
 1421    CNAME record.  If the central trust anchor is compromised, all          
 1427 Dukhovni & Hardaker          Standards Track                   [Page 26]   

 1428 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1431    servers need to be issued new keys by a new TA, and an updated          
 1432    DANE-TA(2) TLSA RRset needs to be published containing just the         
 1433    new TA.                                                                 
 1435    SMTP servers cannot expect broad Certificate Revocation List (CRL) or   
 1436    Online Certificate Status Protocol (OCSP) support from SMTP clients.    
 1437    As outlined above, with DANE, compromised server or trust anchor keys   
 1438    can be "revoked" by removing them from the DNS without the need for     
 1439    client-side support for OCSP or CRLs.                                   
 1441 5.  Digest Algorithm Agility                                               
 1443    While [RFC6698] specifies multiple digest algorithms, it does not       
 1444    specify a protocol by which the SMTP client and TLSA record publisher   
 1445    can agree on the strongest shared algorithm.  Such a protocol would     
 1446    allow the client and server to avoid exposure to deprecated weaker      
 1447    algorithms that are published for compatibility with less capable       
 1448    clients.  When stronger algorithms are an option, deprecated            
 1449    algorithms SHOULD be avoided.  Such a protocol is specified in          
 1450    [RFC7671].  SMTP clients and servers that implement this                
 1451    specification MUST comply with the requirements outlined in Section 9   
 1452    of [RFC7671].                                                           
 1454 6.  Mandatory TLS Security                                                 
 1456    An MTA implementing this protocol may require a stronger security       
 1457    assurance when sending email to selected destinations.  The sending     
 1458    organization may need to send sensitive email and/or may have           
 1459    regulatory obligations to protect its content.  This protocol is not    
 1460    in conflict with such a requirement and, in fact, can often simplify    
 1461    authenticated delivery to such destinations.                            
 1463    Specifically, with domains that publish DANE TLSA records for their     
 1464    MX hostnames, a sending MTA can be configured to use the receiving      
 1465    domain's DANE TLSA records to authenticate the corresponding SMTP       
 1466    server.  Authentication via DANE TLSA records is easier to manage, as   
 1467    changes in the receiver's expected certificate properties are made on   
 1468    the receiver end and don't require manually communicated                
 1469    configuration changes.  With mandatory DANE TLS, when no usable TLSA    
 1470    records are found, message delivery is delayed.  Thus, mail is only     
 1471    sent when an authenticated TLS channel is established to the remote     
 1472    SMTP server.                                                            
 1474    Administrators of mail servers that employ mandatory DANE TLS need to   
 1475    carefully monitor their mail logs and queues.  If a partner domain      
 1476    unwittingly misconfigures its TLSA records, disables DNSSEC, or         
 1477    misconfigures SMTP server certificate chains, mail will be delayed      
 1478    and may bounce if the issue is not resolved in a timely manner.         
 1482 Dukhovni & Hardaker          Standards Track                   [Page 27]   

 1483 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1486 7.  Note on DANE for Message User Agents                                   
 1488    We note that SMTP is also used between Message User Agents (MUAs) and   
 1489    Message Submission Agents (MSAs) [RFC6409].  In [RFC6186], a protocol   
 1490    is specified that enables an MUA to dynamically locate the MSA based    
 1491    on the user's email address.  SMTP connection security considerations   
 1492    for MUAs implementing [RFC6186] are largely analogous to connection     
 1493    security requirements for MTAs, and this specification could be         
 1494    applied largely verbatim with DNS MX records replaced by                
 1495    corresponding DNS Service (SRV) records [RFC7673].                      
 1497    However, until MUAs begin to adopt the dynamic configuration            
 1498    mechanisms of [RFC6186], they are adequately served by more             
 1499    traditional static TLS security policies.  Specification of DANE TLS    
 1500    for MUA-to-MSA SMTP is left to future documents that focus              
 1501    specifically on SMTP security between MUAs and MSAs.                    
 1503 8.  Interoperability Considerations                                        
 1505 8.1.  SNI Support                                                          
 1507    To ensure that the server sends the right certificate chain, the SMTP   
 1508    client MUST send the TLS SNI extension containing the TLSA base         
 1509    domain.  This precludes the use of the Secure Socket Layer (SSL)        
 1510    HELLO that is SSL 2.0 compatible by the SMTP client.                    
 1512    Each SMTP server MUST present a certificate chain (see [RFC5246],       
 1513    Section 7.4.2) that matches at least one of the TLSA records.  The      
 1514    server MAY rely on SNI to determine which certificate chain to          
 1515    present to the client.  Clients that don't send SNI information may     
 1516    not see the expected certificate chain.                                 
 1518    If the server's TLSA records match the server's default certificate     
 1519    chain, the server need not support SNI.  In either case, the server     
 1520    need not include the SNI extension in its TLS HELLO, as simply          
 1521    returning a matching certificate chain is sufficient.  Servers          
 1522    MUST NOT enforce the use of SNI by clients, as the client may be        
 1523    using unauthenticated opportunistic TLS and may not expect any          
 1524    particular certificate from the server.  If the client sends no SNI     
 1525    extension or sends an SNI extension for an unsupported domain, the      
 1526    server MUST simply send some fallback certificate chain of its          
 1527    choice.  The reason for not enforcing strict matching of the            
 1528    requested SNI hostname is that DANE TLS clients are typically willing   
 1529    to accept multiple server names but can only send one name in the SNI   
 1530    extension.  The server's fallback certificate may match a different     
 1531    name acceptable to the client, e.g., the original next-hop domain.      
 1537 Dukhovni & Hardaker          Standards Track                   [Page 28]   

 1538 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1541 8.2.  Anonymous TLS Cipher Suites                                          
 1543    Since many SMTP servers either do not support or do not enable any      
 1544    anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD      
 1545    offer to negotiate a typical set of non-anonymous cipher suites         
 1546    required for interoperability with such servers.  An SMTP client        
 1547    employing pre-DANE opportunistic TLS MAY also include one or more       
 1548    anonymous TLS cipher suites in its TLS HELLO.  SMTP servers that need   
 1549    to interoperate with opportunistic TLS clients SHOULD be prepared to    
 1550    interoperate with such clients by either always selecting a mutually    
 1551    supported non-anonymous cipher suite or correctly handling client       
 1552    connections that negotiate anonymous cipher suites.                     
 1554    Note that while SMTP server operators are under no obligation to        
 1555    enable anonymous cipher suites, no security is gained by sending        
 1556    certificates to clients that will ignore them.  Indeed, support for     
 1557    anonymous cipher suites in the server makes audit trails more           
 1558    informative.  Log entries that record connections that employed an      
 1559    anonymous cipher suite record the fact that the clients did not care    
 1560    to authenticate the server.                                             
 1562 9.  Operational Considerations                                             
 1564 9.1.  Client Operational Considerations                                    
 1566    An operational error on the sending or receiving side that cannot be    
 1567    corrected in a timely manner may, at times, lead to consistent          
 1568    failure to deliver time-sensitive email.  The sending MTA               
 1569    administrator may have to choose between allowing email to queue        
 1570    until the error is resolved and disabling opportunistic or mandatory    
 1571    DANE TLS (Section 6) for one or more destinations.  The choice to       
 1572    disable DANE TLS security should not be made lightly.  Every            
 1573    reasonable effort should be made to determine that problems with mail   
 1574    delivery are the result of an operational error and not an attack.  A   
 1575    fallback strategy may be to configure explicit out-of-band TLS          
 1576    security settings if supported by the sending MTA.                      
 1578    SMTP clients may deploy opportunistic DANE TLS incrementally by         
 1579    enabling it only for selected sites or may occasionally need to         
 1580    disable opportunistic DANE TLS for peers that fail to interoperate      
 1581    due to misconfiguration or software defects on either end.  Some        
 1582    implementations MAY support DANE TLS in an "audit only" mode in which   
 1583    failure to achieve the requisite security level is logged as a          
 1584    warning and delivery proceeds at a reduced security level.  Unless      
 1585    local policy specifies "audit only" or specifies that opportunistic     
 1586    DANE TLS is not to be used for a particular destination, an SMTP        
 1592 Dukhovni & Hardaker          Standards Track                   [Page 29]   

 1593 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1596    client MUST NOT deliver mail via a server whose certificate chain       
 1597    fails to match at least one TLSA record when usable TLSA records are    
 1598    found for that server.                                                  
 1600 9.2.  Publisher Operational Considerations                                 
 1602    Some MTAs enable STARTTLS selectively.  For example, they might only    
 1603    support STARTTLS with clients that have previously demonstrated         
 1604    "proper MTA behavior", e.g., by retrying the delivery of deferred       
 1605    messages (greylisting).  If such an MTA publishes DANE TLSA records,    
 1606    sending MTAs that implement this specification will not attempt the     
 1607    initial cleartext SMTP transaction needed to establish the "proper      
 1608    MTA behavior", because they cannot establish the required channel       
 1609    security.  Server operators MUST NOT implement selective STARTTLS if    
 1610    they also want to support DANE TLSA.                                    
 1612    TLSA Publishers MUST follow the guidelines in Section 8 of [RFC7671].   
 1614    TLSA Publishers SHOULD follow the TLSA publication size guidance        
 1615    found in Section 10.1 of [RFC7671].                                     
 1617    TLSA Publishers SHOULD follow the TLSA record TTL and signature         
 1618    lifetime recommendations found in Section 13 of [RFC7671].              
 1620 10.  Security Considerations                                               
 1622    This protocol leverages DANE TLSA records to implement MITM-resistant   
 1623    Opportunistic Security [RFC7435] for SMTP.  For destination domains     
 1624    that sign their MX records and publish signed TLSA records for their    
 1625    MX hostnames, this protocol allows sending MTAs to securely discover    
 1626    both the availability of TLS and how to authenticate the destination.   
 1628    This protocol does not aim to secure all SMTP traffic, as that is not   
 1629    practical until DNSSEC and DANE adoption are universal.  The            
 1630    incremental deployment provided by following this specification is a    
 1631    best possible path for securing SMTP.  This protocol coexists and       
 1632    interoperates with the existing insecure Internet email backbone.       
 1634    The protocol does not preclude existing non-opportunistic SMTP TLS      
 1635    security arrangements, which can continue to be used as before via      
 1636    manual configuration with negotiated out-of-band key and TLS            
 1637    configuration exchanges.                                                
 1639    Opportunistic SMTP TLS depends critically on DNSSEC for downgrade       
 1640    resistance and secure resolution of the destination name.  If DNSSEC    
 1641    is compromised, it is not possible to fall back on the public CA PKI    
 1642    to prevent MITM attacks.  A successful breach of DNSSEC enables the     
 1643    attacker to publish TLSA usage 3 certificate associations and thereby   
 1647 Dukhovni & Hardaker          Standards Track                   [Page 30]   

 1648 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1651    bypass any security benefit the legitimate domain owner might hope to   
 1652    gain by publishing usage 0 or usage 1 TLSA RRs.  Given the lack of      
 1653    public CA PKI support in existing MTA deployments, avoiding             
 1654    certificate usages 0 and 1 simplifies implementation and deployment     
 1655    with no adverse security consequences.                                  
 1657    Implementations must strictly follow Sections 2.1.2, 2.1.3, 2.2,        
 1658    2.2.1, 2.2.2, 2.2.3, 3.2, and 9.1 of this specification; these          
 1659    sections indicate when it is appropriate to initiate a                  
 1660    non-authenticated connection or cleartext connection to an SMTP         
 1661    server.  Specifically, in order to prevent downgrade attacks on this    
 1662    protocol, implementations must not initiate a connection when this      
 1663    specification indicates that a particular SMTP server must be           
 1664    considered unreachable.                                                 
 1666 11.  References                                                            
 1668 11.1.  Normative References                                                
 1670    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",   
 1671               STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,       
 1672               <http://www.rfc-editor.org/info/rfc1034>.                    
 1674    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
 1675               Requirement Levels", BCP 14, RFC 2119,                       
 1676               DOI 10.17487/RFC2119, March 1997,                            
 1677               <http://www.rfc-editor.org/info/rfc2119>.                    
 1679    [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over    
 1680               Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,   
 1681               February 2002, <http://www.rfc-editor.org/info/rfc3207>.     
 1683    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 1684               Rose, "DNS Security Introduction and Requirements",          
 1685               RFC 4033, DOI 10.17487/RFC4033, March 2005,                  
 1686               <http://www.rfc-editor.org/info/rfc4033>.                    
 1688    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 1689               Rose, "Resource Records for the DNS Security Extensions",    
 1690               RFC 4034, DOI 10.17487/RFC4034, March 2005,                  
 1691               <http://www.rfc-editor.org/info/rfc4034>.                    
 1693    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 1694               Rose, "Protocol Modifications for the DNS Security           
 1695               Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,     
 1696               <http://www.rfc-editor.org/info/rfc4035>.                    
 1702 Dukhovni & Hardaker          Standards Track                   [Page 31]   

 1703 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1706    [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security    
 1707               (TLS) Protocol Version 1.2", RFC 5246,                       
 1708               DOI 10.17487/RFC5246, August 2008,                           
 1709               <http://www.rfc-editor.org/info/rfc5246>.                    
 1711    [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,          
 1712               Housley, R., and W. Polk, "Internet X.509 Public Key         
 1713               Infrastructure Certificate and Certificate Revocation List   
 1714               (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,    
 1715               <http://www.rfc-editor.org/info/rfc5280>.                    
 1717    [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,      
 1718               DOI 10.17487/RFC5321, October 2008,                          
 1719               <http://www.rfc-editor.org/info/rfc5321>.                    
 1721    [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,         
 1722               DOI 10.17487/RFC5598, July 2009,                             
 1723               <http://www.rfc-editor.org/info/rfc5598>.                    
 1725    [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)            
 1726               Extensions: Extension Definitions", RFC 6066,                
 1727               DOI 10.17487/RFC6066, January 2011,                          
 1728               <http://www.rfc-editor.org/info/rfc6066>.                    
 1730    [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and           
 1731               Verification of Domain-Based Application Service Identity    
 1732               within Internet Public Key Infrastructure Using X.509        
 1733               (PKIX) Certificates in the Context of Transport Layer        
 1734               Security (TLS)", RFC 6125, DOI 10.17487/RFC6125,             
 1735               March 2011, <http://www.rfc-editor.org/info/rfc6125>.        
 1737    [RFC6186]  Daboo, C., "Use of SRV Records for Locating Email            
 1738               Submission/Access Services", RFC 6186,                       
 1739               DOI 10.17487/RFC6186, March 2011,                            
 1740               <http://www.rfc-editor.org/info/rfc6186>.                    
 1742    [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the        
 1743               DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,             
 1744               <http://www.rfc-editor.org/info/rfc6672>.                    
 1746    [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication   
 1747               of Named Entities (DANE) Transport Layer Security (TLS)      
 1748               Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698,             
 1749               August 2012, <http://www.rfc-editor.org/info/rfc6698>.       
 1757 Dukhovni & Hardaker          Standards Track                   [Page 32]   

 1758 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1761    [RFC7218]  Gudmundsson, O., "Adding Acronyms to Simplify                
 1762               Conversations about DNS-Based Authentication of Named        
 1763               Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218,            
 1764               April 2014, <http://www.rfc-editor.org/info/rfc7218>.        
 1766    [RFC7671]  Dukhovni, V. and W. Hardaker, "The DNS-Based                 
 1767               Authentication of Named Entities (DANE) Protocol: Updates    
 1768               and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,   
 1769               October 2015, <http://www.rfc-editor.org/info/rfc7671>.      
 1771 11.2.  Informative References                                              
 1773    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
 1774               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,      
 1775               November 1987, <http://www.rfc-editor.org/info/rfc1035>.     
 1777    [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,      
 1778               "Dynamic Updates in the Domain Name System (DNS UPDATE)",    
 1779               RFC 2136, DOI 10.17487/RFC2136, April 1997,                  
 1780               <http://www.rfc-editor.org/info/rfc2136>.                    
 1782    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS              
 1783               Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,   
 1784               <http://www.rfc-editor.org/info/rfc2181>.                    
 1786    [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",         
 1787               FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,         
 1788               <http://www.rfc-editor.org/info/rfc4949>.                    
 1790    [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",   
 1791               STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,       
 1792               <http://www.rfc-editor.org/info/rfc6409>.                    
 1794    [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection       
 1795               Most of the Time", RFC 7435, DOI 10.17487/RFC7435,           
 1796               December 2014, <http://www.rfc-editor.org/info/rfc7435>.     
 1798    [RFC7673]  Finch, T., Miller, M., and P. Saint-Andre, "Using            
 1799               DNS-Based Authentication of Named Entities (DANE) TLSA       
 1800               Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673,   
 1801               October 2015, <http://www.rfc-editor.org/info/rfc7673>.      
 1812 Dukhovni & Hardaker          Standards Track                   [Page 33]   

 1813 RFC 7672        SMTP Security via Opportunistic DANE TLS    October 2015   
 1816 Acknowledgements                                                           
 1818    The authors would like to extend great thanks to Tony Finch, who        
 1819    started the original version of a DANE SMTP document.  His work is      
 1820    greatly appreciated and has been incorporated into this document.       
 1821    The authors would like to additionally thank Phil Pennock for his       
 1822    comments and advice on this document.                                   
 1824    Acknowledgements from Viktor: Thanks to Paul Hoffman, who motivated     
 1825    me to begin work on this memo and provided feedback on early draft      
 1826    versions of this document.  Thanks to Patrick Koetter, Perry Metzger,   
 1827    and Nico Williams for valuable review comments.  Thanks also to         
 1828    Wietse Venema, who created Postfix, and whose advice and feedback       
 1829    were essential to the development of the Postfix DANE implementation.   
 1831 Authors' Addresses                                                         
 1833    Viktor Dukhovni                                                         
 1834    Two Sigma                                                               
 1836    Email: ietf-dane@dukhovni.org                                           
 1839    Wes Hardaker                                                            
 1840    Parsons                                                                 
 1841    P.O. Box 382                                                            
 1842    Davis, CA  95617                                                        
 1843    United States                                                           
 1845    Email: ietf@hardakers.net                                               
 1867 Dukhovni & Hardaker          Standards Track                   [Page 34]   
section-3.2.2 Viktor Dukhovni(Technical Erratum #6283) [Reported]
based on outdated version
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 employ the TLSA base domain as the primary reference identifier
   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 a second reference identifier.
      The CNAME-expanded original next-hop domain MUST be included as a
      third reference identifier if different from the 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.
It should say:
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 employ the TLSA base domain as the primary reference identifier
   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 a second reference identifier.
      The CNAME-expanded original next-hop domain MUST be included as a
      third reference identifier if different from the original next-hop
      domain.  When the client MTA is employing DANE TLS security
      despite "insecure" MX redirection, the MX hostnameTLSA base domain is the only
      reference identifier.

The first paragraph of 3.2.2 makes it clear that the TLSA base domain is the primary reference identifier in all cases. The last sentence of the second paragraph inadvertently contradicts this in the case the the TLSA base domain is a CNAME expansion of the input MX hostname.

The corrected text replaces "... the MX hostname is the only reference identifier" with "... the TLSA base domain is the only reference identifier".