One document matched: draft-ietf-dane-smtp-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
 <!ENTITY rfc2033 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2033.xml">
 <!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
 <!ENTITY rfc3207 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3207.xml">
 <!ENTITY rfc3461 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3461.xml">
 <!ENTITY rfc3464 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3464.xml">
 <!ENTITY rfc3848 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3848.xml">
 <!ENTITY rfc4033 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
 <!ENTITY rfc4035 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
 <!ENTITY rfc4409 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4409.xml">
 <!ENTITY rfc4954 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4954.xml">
 <!ENTITY rfc5068 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5068.xml">
 <!ENTITY rfc5234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
 <!ENTITY rfc5246 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
 <!ENTITY rfc5280 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
 <!ENTITY rfc5321 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">
 <!ENTITY rfc5322 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml">
 <!ENTITY rfc5598 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5598.xml">
 <!ENTITY rfc5890 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
 <!ENTITY rfc6066 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
 <!ENTITY rfc6125 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml">
 <!ENTITY rfc6186 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6186.xml">
 <!ENTITY rfc6698 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!-- autobreaks="yes" -->
<?rfc comments="yes" ?> <?rfc inline="yes" ?>
<?rfc compact="yes" ?> <?rfc subcompact="no" ?>
<!-- editing="no" -->
<?rfc iprnotified="no" ?>
<!-- linkmailto="yes" -->
<!-- private="" --> <!-- header="" --> <!-- footer="" -->
<!-- slides="no" --> <!-- background="" -->
<!-- sortrefs="no" --> <?rfc symrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?> <!-- tocompact="yes" --> <!-- tocdepth="3" --> <!-- tocindent="yes" -->
<!-- topblock="no" -->

<!-- $Cambridge: hermes/doc/qsmtp/draft-fanf-dane-smtp.xml,v 1.43 2013/02/25 23:43:49 fanf2 Exp $ -->

<rfc ipr="trust200902"
     category="std"
     docName="draft-ietf-dane-smtp-01">

<!-- === -->
 <front>

  <title abbrev="SMTP with TLSA">
    Secure SMTP using DNS-Based Authentication of Named Entities (DANE) TLSA records.
  </title>

  <author initials="T." surname="Finch" fullname="Tony Finch">
   <organization abbrev="University of Cambridge">
    University of Cambridge Computing Service
   </organization>
   <address>
    <postal>
     <street>New Museums Site</street>
     <street>Pembroke Street</street>
     <city>Cambridge</city>
     <code>CB2 3QH</code>
     <country>ENGLAND</country>
    </postal>
    <phone>+44 797 040 1426</phone>
    <email>dot@dotat.at</email>
    <uri>http://dotat.at/</uri>
   </address>
  </author>

  <date month="February" year="2013"/>

  <area>Security</area>
  <workgroup>DNS-Based Authentication of Named Entities (DANE)</workgroup>

  <abstract>

   <t>SMTP has a STARTTLS extension, but (especially in the case of
    inter-domain mail transfer) it only provides very limited security
    because it does not specify how to authenticate the server's
    certificate. This memo specifies how TLSA records in the DNS can
    be used for proper SMTP server authentication.</t>

  </abstract>

 </front>

 <middle>

<!-- === -->

  <section anchor="intro" title="Introduction">

   <t>The specification for SMTP over TLS <xref target="RFC3207"/>
    does not describe how to authenticate a server: which identity
    relating to the connection ought to be authenticated by the
    server's certificate. In practice, most certificates presented by
    publicly-referenced SMTP servers either cannot be validated with
    respect to a well-known certification authority, or do not verify
    any identity expected by the client.</t>

   <t>As a result, inter-domain SMTP clients cannot require working
    server authentication if they want to successfully send mail using
    TLS. Therefore TLS currently provides only a limited amount of
    additional security for inter-domain SMTP. Its encryption protects
    against on-path passive eavesdropping; but it does not protect
    against an active attack, since the client has no way to detect
    when an attacker is spoofing the server.</t>

   <t>This memo describes how to fix this
    using DNSSEC <xref target="RFC4033"/>
    and TLSA records <xref target="RFC6698"/>
    set up as described in <xref target="I-D.ietf-dane-srv"/>.
    To summarize, we use DNSSEC to secure the association between a
    mail domain and its SMTP server host names (i.e. the MX recods),
    and between the host names and their certificates (using TLSA
    records). Connections to servers are authenticated by their TLS
    certificates. The existance of TLSA records also signals to the
    client that it can expect the server to offer TLS with a valid
    certificate.</t>

   <t>The security situation is better for intra-domain SMTP, because
    in this case the client and server can be configured with prior
    knowledge of how to authenticate each other. This specification
    can also be used for authenticating servers in intra-domain
    SMTP.</t>

   <t>This memo does not cover message submission
    <xref target="RFC4409"/> <xref target="RFC5068"/> <xref target="RFC6186"/>,
    nor does it cover LMTP <xref target="RFC2033"/>,
    since they use the DNS in a different way than MTA-to-MTA SMTP.</t>

   <t>The protocol described in this memo adds new security checks
    that can cause email delivery to be delayed when a security
    failure is detected. We specify that clients treat such problems
    as a "temporary failure", causing the message to be queued for a
    later delivery attempt, in the hope that the attack (or
    configuration error) will have been dealt with.</t>

  </section>

<!-- === -->

  <section title="Terminology">

   <t><list style="hanging">

    <t hangText="ADMD:">
     An ADministrative Management Domain, as described in the Internet
     Mail Architecture <xref target="RFC5598"/>.
    </t>

    <t hangText="Inter-domain SMTP:">
     SMTP between different ADMDs across the public Internet, where a
     client MTA sends mail to a publicly-referenced SMTP server MTA.
    </t>

    <t hangText="Intra-domain SMTP:">
     SMTP between MTAs within an ADMD.
    </t>

    <t hangText="Mail domain:">
     The part of an email address after the "@"; also the query name
     for a (possibly implicit) MX record.
    </t>

    <t hangText="MX resolution:">
     The algorithm for resolving a mail domain into a set of SMTP
     server hosts, described in <xref target="RFC5321"/> section 5.
    </t>

    <t hangText="Publicly-referenced SMTP server:">
     An SMTP server which runs on port 25 of an Internet host located
     using MX resolution. (This term is from
     <xref target="RFC3207"/>.)
    </t>

    <t hangText="SMTP server host name:">
     The target of a (possibly implicit) MX record.
    </t>

   </list></t>

   <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    memo are to be interpreted as described in <xref target="RFC2119"/>.</t>

  </section>

<!-- === -->

  <section anchor="details" title="Inter-domain SMTP with TLSA">

   <t>This is a combination of the usual MX resolution algorithm
    described in <xref target="RFC5321"/> section 5, and the rules for
    using DANE TLSA records with SRV and MX records
    <xref target="I-D.ietf-dane-srv"/>. The former determines the
    server ordering and selection rules (which differ slightly from
    the rules for SRV records, for instance, in the case of backup MX
    relaying). The latter determines the rules for handling TLSA
    records.</t>

   <t>Note the difference between the (effective) absence of TLSA
    records, and the presence of unusable TLSA records. If a server
    has no TLSA records, or their DNSSEC validation status is
    "indeterminate" or "insecure", the client can attempt to deliver
    to this server insecurely (which might be over unauthenticated
    TLS, as described in the introduction). If a server has TLSA
    records whose DNSSEC validation status is "secure", whether they
    are usable or not, the client MUST use TLS to connect to the
    server and validate the certificate according to
    <xref target="I-D.ietf-dane-srv"/> section 3.</t>

  </section>

<!-- === -->

  <section title="Intra-domain SMTP with TLSA">

   <t>Mail transmission within an ADMD can be based on MX records
    (such as when delivering incoming mail to its destination host) or
    on statically configured host names (such as when routing outgoing
    mail via a border relay).</t>

   <t>When routing internal mail using MX records,
    <xref target="details"/> applies the same as for inter-domain
    SMTP.</t>

   <t>When routing mail using host names, the MX lookup step is
    skipped and TODO need a better explanation.</t>

  </section>

<!-- === -->

  <section anchor="security" title="Security considerations">

   <t>This memo provides only conditional security. It allows a server
    to publish in the DNS the details of how it can be authenticated.
    Clients that implement this protocol can use it to provide a
    strong guarantee that they are sending mail to the correct place.
    If either of these is missing, mail delivery will be insecure.</t>

   <t>In addition to the following, many security considerations are
    covered in <xref target="I-D.ietf-dane-srv"/>.</t>

   <section title="Temporary failures and denial of service">

    <t>Many provisioning failures in SMTP cause "permanent" failures,
     that is the immediate and final rejection of the message. This
     includes missing DNS records, an SMTP server that is not
     configured to accept mail for the recipient domain, and so
     forth.</t>

    <t>In this protocol, provisioning an incorrect TLS certificate
     triggers a temporary error. This is because we want to minimise
     the damage that occurs when an on-path attacker intercepts the TCP
     connection between an SMTP client and server. An attacker can
     cause delays, but is not able to trigger immediate delivery
     failures.</t>

   </section>

   <section title="Deliberate omissions">

    <t>This memo does not specify any changes to SMTP client
     authentication. Inter-domain SMTP client authentication remains
     extremely weak. Intra-domain SMTP can be configured as strong as
     necessary (using SMTP AUTH or TLS client certificates, for
     instance) but that is out of scope for this memo.</t>

   </section>

  </section>

<!-- === -->

  <section title="Internationalization Considerations">

   <t>If any of the DNS queries are for an internationalized domain
    name, then they need to use the A-label form
    <xref target="RFC5890"/>. TODO: this section needs checking WRT
    IMA.</t>

  </section>

<!-- === -->

  <section title="IANA Considerations">

   <t>No IANA action is required.</t>

  </section>

<!-- === -->

  <section title="Acknowledgements">

   <t>Thanks to Mark Andrews for arguing that authenticating the SMTP
    server host name is the right thing, and that we ought to rely on
    DNSSEC to secure the MX lookup. Thanks to James Cloos, Ned Freed,
    Olafur Gudmundsson, Paul Hoffman, Phil Pennock, Hector Santos,
    Jonas Schneider, and Alessandro Vesely for helpful
    suggestions.</t>

  </section>

<!-- === -->

 </middle>

 <back>

<!-- === -->

  <references title="Normative References">

   &rfc2119; <!-- MUSTard MAYonnaise -->
   &rfc3207; <!-- SMTP STARTTLS extension -->
   &rfc4033; <!-- DNSSEC overview -->
   &rfc5321; <!-- ESMTP -->
   &rfc5890; <!-- IDNA -->
   &rfc6698; <!-- DANE TLSA -->

   <reference anchor="I-D.ietf-dane-srv">
    <front>
     <title>Using DNS-Based Authentication of Named Entities (DANE)
      TLSA records with SRV and MX records.</title>
     <author initials="T" surname="Finch" fullname="Tony Finch" />
     <date month="March" year="2013" />
    </front>
    <seriesInfo name="Internet-Draft" value="draft-ietf-dane-srv" />
   </reference>

  </references>

  <references title="Informative References">

   &rfc2033; <!-- LMTP -->
   &rfc4409; <!-- Mesasge submission -->
   &rfc5068; <!-- Message submission ops -->
   &rfc5598; <!-- Internet Mail Architecture -->
   &rfc6186; <!-- SRV for mail clients -->

  </references>

<!-- === -->

  <section title="Example">

   <t>In the following, most of the DNS resource data is elided for
    simplicity.</t>

   <t><figure>
    <artwork><![CDATA[
; mail domain
example.com.              MX      1 mx.example.net.
example.com.              RRSIG   MX ...

; SMTP server host name
mx.example.net.           A      192.0.2.1
mx.example.net.           AAAA   2001:db8:212:8::e:1

; TLSA resource record
_25._tcp.mx.example.net.  TLSA   ...
_25._tcp.mx.example.net.  RRSIG  TLSA ...
    ]]></artwork>
   </figure></t>

   <t>Mail for addresses at example.com is delivered by SMTP to
    mx.example.net. Connections to mx.example.net port 25 that use
    STARTTLS will get a server certificate that authenticates the name
    mx.example.net.</t>

  </section>

<!-- === -->

  <section title="Change log">

   <section title="Changes in version -01">

    <t>Strip the document down so it is now based on
     <xref target="I-D.ietf-dane-srv"/>.</t>

    <t>Drop the Transmitted: header idea.</t>

   </section>

   <section title="Changes in version -00">

    <t>Change doc name from draft-fanf-dane-smtp to draft-ietf-dane-smtp.</t>

    <t>Update DANE citation to published RFC.</t>

    <t>Be clearer about the PKIX certificate validation vs.
     certificate subject name matching.</t>

    <t>Minor clarifications suggested by Phill Hallam-Baker and James Cloos.</t>

   </section>

   <section title="Changes in version fanf-04">

    <t>Add some questions for reviewers</t>

    <t>Add a note about stub resolvers and the AD bit.</t>

    <t>Internationalization considerations.</t>

   </section>

   <section title="Changes in version fanf-03">

    <t>Clarify how to use SNI with this protocol.</t>

    <t>Clarify lack of changes to MX sorting rules.</t>

    <t>Mention DNAME as well as CNAME.</t>

    <t>An example.</t>

   </section>

   <section title="Changes in version fanf-02">

    <t>Clarify the wording that describes how a client determines that
     this protocol is in effect.</t>

    <t>Divide the security considerations into sub-sections, and add a
     subsection on denial of service.</t>

    <t>Clarify intro, mentioning TLSA owner name format.</t>

    <t>Extend the scope to cover MTA-to-MTA mail within an ADMD as
     well as between ADMDs.</t>

   </section>

   <section title="Changes in version fanf-01">

    <t>More about why not to authenticate mail domains in the rationale.</t>

    <t>Change DNS-ID requirement from MUST to SHOULD to follow RFC 6125.</t>

    <t>Acknowledgments section.</t>

    <t>Transmitted: header trace field. Not sure if this is a good
     idea; feedback wanted.</t>

    <t>"dane" MTA-name-type for use in DSNs. Even less sure if this is
     a good idea.</t>

   </section>

  </section>

<!-- === -->

 </back>

</rfc>