One document matched: draft-fanf-dane-smtp-00.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 rfc4033 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
 <!ENTITY rfc6066 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
 <!ENTITY rfc5321 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">
 <!ENTITY rfc5598 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5598.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.7 2012/05/25 17:06:49 fanf2 Exp $ -->

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

<!-- === -->
 <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. A 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 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.</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 MUST 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>

   <t>The client MAY wish to insert a header at the start of the
    message to record the fact that it authenticated the server.
    XXX: Perhaps the form of this header should be specified here.</t>

  </section>

<!-- === -->

  <section title="IANA Considerations">

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

  </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 way for a server to tell if a client has
    authenticated it using this protocol, since SMTP has no mechanism
    to signal this information.</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. Inconsistencies 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 make any changes to SMTP client
    authentication. Inter-domain SMTP client authentication remains
    extremely weak.</t>

  </section>

<!-- === -->

 </middle>

 <back>

<!-- === -->

  <references title="Normative References">

   &rfc2119; <!-- MUSTard MAYonnaise -->
   &rfc3207; <!-- SMTP-over-TLS -->
   &rfc4033; <!-- DNSSEC -->
   &rfc5321; <!-- ESMTP -->
   &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>

  </section>

<!-- === -->

 </back>

</rfc>