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

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
 <!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 rfc4954 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4954.xml">
 <!ENTITY rfc5234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.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 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">
]>

<?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.14 2012/05/29 20:06:59 fanf2 Exp $ -->

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

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

  <title abbrev="SMTP with TLSA">
    Secure inter-domain SMTP with TLS, DNSSEC and 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="May" year="2012"/>

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

  <abstract>

   <t>SMTP supports STARTTLS for inter-domain mail transfer, but it
    only provides very limited security because the server's
    certificate cannot be authenticated. This memo specifies how TLSA
    records in the DNS can be used for proper MX target 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="I-D.ietf-dane-protocol"/>.</t>

   <t>We use DNSSEC to secure the association between a mail domain
    and its SMTP server host names. Each server's TLS certificate
    authenticates its host name.</t>

   <t>As well as its normal function of providing an association
    between a domain name and a certificate, we are also using the
    existance of a TLSA record to signal to the client that it can
    expect a valid server certificate.</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 a 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="SMTP server host name:">
     The target of a (possibly implicit) MX record.
    </t>

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

    <t hangText="Mail domain:">
     The part of an email address after the "@"; also the owner name
     of 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>

   </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="Details of SMTP with TLSA">

   <t>In the following we describe some additions to the usual MX
    resolution algorithm described in <xref target="RFC5321"/> section
    5. If there is any conflict between <xref target="RFC5321"/> and
    this memo, that is an error in this memo.</t>

   <t>The client SHALL look up the MX RRset for the mail domain. There
    are three succesful results that yield a list of SMTP server host
    names:

    <list style="symbols">

     <t>A list of one or more MX records;</t>

     <t>An implicit MX record, in lieu of an empty list of MX records;</t>

     <t>A CNAME to a successful result.</t>

    </list>
   </t>

   <t>If the lookup is not successful, the client SHALL proceed as
    usual.</t>

   <t>All of these DNS RRsets MUST be "secure" according to DNSSEC
    validation (<xref target="RFC4033"/> section 5). In the case of an
    implicit MX record, there MUST be a secure denial of existence of
    an MX RRset for the mail domain. In the case of a (chain of) CNAME
    RRs, all the CNAMEs MUST be secure as well as their ultimate
    target.</t>

   <t>If any of the responses is "bogus", the client MUST treat this
    as a temporary error.</t>

   <t>If these security requirements are not satisfied, this protocol
    does not take effect. The client SHOULD fall back to insecure
    delivery (which might be over unauthenticated TLS).</t>

   <t>The client now has an authentic list of SMTP server host names
    and priority values. It processes this list as usual.</t>

   <t>The rest of this section applies to each SMTP server host name
    individually.</t>

   <t>When connecting to a server, the client SHALL look up its TLSA
    RRset as described in <xref target="I-D.ietf-dane-protocol"/>
    section 3. That is, the TLSA RRset owner name SHALL be
    "_25._tcp.hostname" where "hostname" is the SMTP server host name.
    The response can be one of the following (as listed in
    <xref target="I-D.ietf-dane-protocol"/> section 4.1):

    <list style="symbols">

     <t>A secure answer containing one or more TLSA records, in which
      case the client SHALL proceed as descrbed below.</t>

     <t>A bogus answer, which the client SHALL treat as a temporary
      error.</t>

     <t>In the other cases the client SHOULD deliver to this server
      insecurely (which might be over unauthenticated TLS).</t>

    </list>
   </t>

   <t>The client now has one or more TLSA records for the server it is
    connecting to.</t>

   <t>The client MUST ensure that the server offers the STARTTLS
    service extension <xref target="RFC3207"/> in its response to the
    client's EHLO command (<xref target="RFC5321"/> section 4.1.1.1).</t>

   <t>The client SHALL then issue the STARTTLS command which MUST be
    successful. It then proceeds with TLS negotiation.</t>

   <t>The client SHALL validate the server's certificate as described
    in <xref target="I-D.ietf-dane-protocol"/> section 2.1.</t>

   <t>The client SHALL verify the server's identity as described in
    <xref target="RFC6125"/> section 6. Its list of reference
    identifiers SHOULD include the SMTP server host name with type
    DNS-ID, and MAY include a second copy of the host name with type
    CN-ID.</t>

   <t>If any of these checks fail, the client MUST disconnect from the
    server and treat this as a temporary failure.</t>

   <t>The client can now proceed to deliver mail securely.</t>

  </section>

<!-- === -->

  <section title="The Transmitted: header field">

   <t>The client MAY wish to insert a Transmitted: header field at the
    start of the message header just before transmitting the message.
    This records the result of the checks specified in the previous
    section. This is a client-side counterpart to the Received: header
    field (<xref target="RFC5321"/> section 4.4) and has very similar
    syntax. It SHOULD be treated as a trace field.</t>

   <t>The syntax of the Transmitted: header field is described using
    ABNF <xref target="RFC5234"/>. Non-terminal syntax rules not
    defined in this memo are defined in <xref target="RFC5321"/>, or
    <xref target="RFC5322"/>, or <xref target="RFC5234"/>.</t>

   <t><figure>
    <artwork><![CDATA[
Transmitted-line  = "Transmitted:" FWS To-domain By-domain
                             Opt-info [CFWS] ";" date-time CRLF

To-domain         = "TO" FWS Extended-Domain
    ]]></artwork>
   </figure></t>

   <t>A <Transmitted-line> SHALL include:
    <list style="symbols">

     <t>A <To-domain> clause describing the SMTP server. The
      <Domain> part of a <To-domain> SHALL be the same as
      the SMTP server host name.</t>

     <t>A <By-domain> clause identifying the SMTP client that
      added the header. (If the client also acts as a server this is
      the same <By-domain> clause it would include in any
      Received: header fields it adds.) This clause helps with
      recovery if the original order of a message header's fields has
      been lost.</t>

     <t>Various <Opt-info> clauses, which MUST include a
      <With> clause. The <Protocol> part of this clause is
      used to indicate whether the client successfully authenticated
      the server, using one of the types specified in
      <xref target="with"/>.</t>

     <t>And a <date-time> to further help with disordering in
      case a message is transmitted by the same client more than
      once.</t>

    </list></t>

  </section>

<!-- === -->

  <section title="IANA Considerations">

   <section anchor="with" title=""with" protocol types">

    <t>The "with" protocol type registry includes a number of keywords
     that indicate the use of SMTP with or without TLS and/or AUTH
     <xref target="RFC3848"/>. When these types appear in a
     Transmitted: header field "with" clause they indicate that the
     client did not authenticate the server as described in
     <xref target="details"/>.</t>

    <t><list style="symbols">

      <t>The new keyword "ESMTPT" indicates the use of ESMTP
       <xref target="RFC5321"/> with STARTTLS <xref target="RFC3207"/>
       when the client successfully authenticated the server.</t>

      <t>The new keyword "ESMTPTA" indicates the use of ESMTP
       <xref target="RFC5321"/> with STARTTLS <xref target="RFC3207"/>
       and AUTH <xref target="RFC4954"/> when the client successfully
       authenticated the server.</t>

    </list></t>

    <t>These new keywords are not for use in Received: header fields
     since the server cannot tell whether or not the client
     authenticated it.</t>

    <t>There are no keywords corresponding to a client trying and
     failing to authenticate the server, since in this case no message
     transmission occurs.</t>

   </section>

   <section title="Permanent message header field registration">

    <t><list style="hanging">

      <t hangText="Header field name:"> Transmitted: </t>

      <t hangText="Applicable protocol:"> mail </t>

      <t hangText="Status:"> standard </t>

      <t hangText="Change controller:"> IETF </t>

      <t hangText="Specification document"> this memo </t>

    </list></t>

   </section>

   <section title=""dane" MTA-name-type">

    <t>Delivery status notifications <xref target="RFC3464"/> can
     include a Remote-MTA field recording an SMTP server host name.
     When this has been authenticated according to
     <xref target="details"/> the reporting MTA MAY use an
     MTA-type-name of "dane".</t>

    <t><list style="letters">

      <t>MTA-type-name: "dane"</t>

      <t>Syntax: same as the "dns" MTA-type-name <xref target="RFC3461"/></t>

      <t>Translation into US-ASCII: none needed</t>

    </list></t>

   </section>

  </section>

<!-- === -->

  <section 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.</t>

   <t>There is no secure way for a server to tell if a client has
    authenticated it using this protocol. This is a general limitation
    of TLS. The Transmitted: header field records this information for
    tracing and debugging, not for security purposes.</t>

   <t>By signing their zone with DNSSEC, a mail domain owner
    implicitly instructs SMTP clients to check their SMTP server TLSA
    records. This implies another point in the trust relationship
    between mail domain owner and smtp server operator. Most of the
    setup requirements for this protocol fall on the SMTP server
    operator: installing a TLS certificate with the correct name, and
    publishing a TLSA record under that name. If these are not correct
    then mail delivery from TLSA-aware clients might be delayed.</t>

   <t>We do not specify that clients check that all of a mail domain's
    SMTP server host names consistently have or do not have TLSA
    records. This is so that partial or incremental deployment does
    not break mail delivery. Different levels of deployment are likely
    if a domain has a third-party backup MX, for example.</t>

   <t>We do not specify that clients check the DNSSEC state of the
    SMTP server address records. This is not necessary since the
    certificate checks ensure that the client has connected to the
    correct server. (The address records will normally have the same
    security state as the TLSA records, but they can differ if there
    are CNAME or DNAME indirections.)</t>

   <t>This memo does not specify any changes to SMTP client
    authentication. Inter-domain SMTP client authentication remains
    extremely weak.</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 should rely on
    DNSSEC to secure the MX lookup. Thanks to Ned Freed and Alessandro
    Vesely for helpful suggestions.</t>

  </section>

<!-- === -->

 </middle>

 <back>

<!-- === -->

  <references title="Normative References">

   &rfc2119; <!-- MUSTard MAYonnaise -->
   &rfc3207; <!-- SMTP STARTTLS extension -->
   &rfc3461; <!-- SMTP DSN extension -->
   &rfc3464; <!-- DSN messages -->
   &rfc3848; <!-- "with" protocols -->
   &rfc4033; <!-- DNSSEC -->
   &rfc4954; <!-- SMTP AUTH extension -->
   &rfc5234; <!-- ABNF -->
   &rfc5321; <!-- ESMTP -->
   &rfc5322; <!-- Message format -->
   &rfc6125; <!-- certificate verification -->

   <reference anchor='I-D.ietf-dane-protocol'>
    <front>
     <title>The DNS-Based Authentication of Named Entities (DANE)
      Transport Layer Security (TLS) Protocol: TLSA</title>
     <author initials='P' surname='Hoffman' fullname='Paul Hoffman' />
     <author initials='J' surname='Schlyter' fullname='Jakob Schlyter' />
     <date month='May' day='17' year='2012' />
    </front>
    <seriesInfo name='Internet-Draft' value='draft-ietf-dane-protocol-21' />
    <format type='TXT'
     target='http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-21.txt' />
   </reference>

  </references>

  <references title="Informative References">

   &rfc6066; <!-- TLS extensions -->
   &rfc5598; <!-- Internet Mail Architecture -->

  </references>

<!-- === -->

  <section title="Rationale - choice of certificate identity">

   <t>There are a number of reasons for the certificate to
    authenticate the SMTP server host name rather than the mail
    domain.</t>

   <t>SMTP allows a client to transfer mail to recipients at multiple
    domains in the same connection. If the certificate identifies the
    host name then it does not need to list all the possible mail
    domains.</t>

   <t>It is not in general feasible for the server to select a mail
    domain certificate based on the recipient domains when the
    connection is established (using Server Name Indication,
    <xref target="RFC6066"/> section 3), because an SMTP client might
    not know all of the recipients when it establishes the
    connection.</t>

   <t>Outgoing SMTP relays and message submission servers handle mail
    for any domain, so in those cases the only sensible option is for
    the certificate to contain the host name. It is more consistent
    for incoming MX server certificates to match.</t>

   <t>It is common for SMTP servers to act in multiple roles, as
    outgoing relays or as incoming MX servers, depending on the client
    identity. It is simpler if the server can present the same
    certificate regardless of the role in which it is to act.</t>

   <t>Sometimes the server does not know its role until the client has
    authenticated, which usually occurs after TLS has been
    established.</t>

   <t>This protocol does not provide an option for directly
    authenticating the mail domain because that would add complexity
    without providing any benefit, and security protocols are best
    kept simple. As described above, there are real-world cases where
    authenticating the mail domain cannot be made to work, so there
    are complicated criteria for when mail domain TLSA records might
    be used and when they cannot. This is all avoided by
    authenticating the SMTP server host name.</t>

   <t>Finally, this protocol only affects the logic in the SMTP client
    and requires no additional SMTP server functionality, such as
    support for the TLS Server Name Indication extension.</t>

  </section>

<!-- === -->

  <section title="Change log">

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

    <t>More about 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>