Docs: clarify client-side auth options for smtp transport
[users/heiko/exim.git] / doc / doc-txt / draft-ietf-dane-smtp-with-dane.txt
index 26bed33a5a048f055bc0f447c0735e0ec55236dc..70ae5d66dfc7a8ddf4a69e9209d98d164467cc78 100644 (file)
@@ -5,12 +5,12 @@
 DANE                                                         V. Dukhovni
 Internet-Draft                                                 Two Sigma
 Intended status: Standards Track                             W. Hardaker
 DANE                                                         V. Dukhovni
 Internet-Draft                                                 Two Sigma
 Intended status: Standards Track                             W. Hardaker
-Expires: February 3, 2015                                        Parsons
-                                                          August 2, 2014
+Expires: February 18, 2015                                       Parsons
+                                                         August 17, 2014
 
 
                 SMTP security via opportunistic DANE TLS
 
 
                 SMTP security via opportunistic DANE TLS
-                   draft-ietf-dane-smtp-with-dane-11
+                   draft-ietf-dane-smtp-with-dane-12
 
 Abstract
 
 
 Abstract
 
@@ -36,7 +36,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on February 3, 2015.
+   This Internet-Draft will expire on February 18, 2015.
 
 Copyright Notice
 
 
 Copyright Notice
 
@@ -53,7 +53,7 @@ Copyright Notice
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015                [Page 1]
+Dukhovni & Hardaker     Expires February 18, 2015               [Page 1]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -91,25 +91,25 @@ Table of Contents
        3.2.3.  Reference identifier matching . . . . . . . . . . . .  25
    4.  Server key management . . . . . . . . . . . . . . . . . . . .  26
    5.  Digest algorithm agility  . . . . . . . . . . . . . . . . . .  26
        3.2.3.  Reference identifier matching . . . . . . . . . . . .  25
    4.  Server key management . . . . . . . . . . . . . . . . . . . .  26
    5.  Digest algorithm agility  . . . . . . . . . . . . . . . . . .  26
-   6.  Mandatory TLS Security  . . . . . . . . . . . . . . . . . . .  28
-   7.  Note on DANE for Message User Agents  . . . . . . . . . . . .  29
-   8.  Interoperability considerations . . . . . . . . . . . . . . .  29
-     8.1.  SNI support . . . . . . . . . . . . . . . . . . . . . . .  29
-     8.2.  Anonymous TLS cipher suites . . . . . . . . . . . . . . .  30
-   9.  Operational Considerations  . . . . . . . . . . . . . . . . .  30
-     9.1.  Client Operational Considerations . . . . . . . . . . . .  30
-     9.2.  Publisher Operational Considerations  . . . . . . . . . .  31
-   10. Security Considerations . . . . . . . . . . . . . . . . . . .  31
-   11. IANA considerations . . . . . . . . . . . . . . . . . . . . .  32
-   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  32
-   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  33
-     13.1.  Normative References . . . . . . . . . . . . . . . . . .  33
-     13.2.  Informative References . . . . . . . . . . . . . . . . .  34
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34
-
-
-
-Dukhovni & Hardaker     Expires February 3, 2015                [Page 2]
+   6.  Mandatory TLS Security  . . . . . . . . . . . . . . . . . . .  27
+   7.  Note on DANE for Message User Agents  . . . . . . . . . . . .  27
+   8.  Interoperability considerations . . . . . . . . . . . . . . .  28
+     8.1.  SNI support . . . . . . . . . . . . . . . . . . . . . . .  28
+     8.2.  Anonymous TLS cipher suites . . . . . . . . . . . . . . .  28
+   9.  Operational Considerations  . . . . . . . . . . . . . . . . .  29
+     9.1.  Client Operational Considerations . . . . . . . . . . . .  29
+     9.2.  Publisher Operational Considerations  . . . . . . . . . .  30
+   10. Security Considerations . . . . . . . . . . . . . . . . . . .  30
+   11. IANA considerations . . . . . . . . . . . . . . . . . . . . .  31
+   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  31
+   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
+     13.1.  Normative References . . . . . . . . . . . . . . . . . .  31
+     13.2.  Informative References . . . . . . . . . . . . . . . . .  32
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33
+
+
+
+Dukhovni & Hardaker     Expires February 18, 2015               [Page 2]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -165,7 +165,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015                [Page 3]
+Dukhovni & Hardaker     Expires February 18, 2015               [Page 3]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -221,7 +221,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015                [Page 4]
+Dukhovni & Hardaker     Expires February 18, 2015               [Page 4]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -277,7 +277,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015                [Page 5]
+Dukhovni & Hardaker     Expires February 18, 2015               [Page 5]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -333,7 +333,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015                [Page 6]
+Dukhovni & Hardaker     Expires February 18, 2015               [Page 6]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -389,7 +389,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015                [Page 7]
+Dukhovni & Hardaker     Expires February 18, 2015               [Page 7]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -445,7 +445,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015                [Page 8]
+Dukhovni & Hardaker     Expires February 18, 2015               [Page 8]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -497,11 +497,11 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    and "anchorless" RRsets MUST be handled identically: in either case
    unvalidated data for the query domain is all that is and can be
    available, and authentication using the data is impossible.  In what
    and "anchorless" RRsets MUST be handled identically: in either case
    unvalidated data for the query domain is all that is and can be
    available, and authentication using the data is impossible.  In what
-   follows, the term "insecure" will also includes the case of
+   follows, the term "insecure" will also include the case of
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015                [Page 9]
+Dukhovni & Hardaker     Expires February 18, 2015               [Page 9]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -557,7 +557,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 10]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 10]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -613,7 +613,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 11]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 11]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -669,7 +669,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 12]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 12]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -725,7 +725,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 13]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 13]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -739,7 +739,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    any relevant security policy configured by the MTA administrator.
    Similarly, when an MX RRset incorrectly lists a network address in
    lieu of an MX hostname, if an MTA chooses to connect to the network
    any relevant security policy configured by the MTA administrator.
    Similarly, when an MX RRset incorrectly lists a network address in
    lieu of an MX hostname, if an MTA chooses to connect to the network
-   address in the non-conformat MX record, DANE TLSA does not apply for
+   address in the non-conformant MX record, DANE TLSA does not apply for
    such a connection.
 
    In the subsections that follow we explain how to locate the SMTP
    such a connection.
 
    In the subsections that follow we explain how to locate the SMTP
@@ -781,7 +781,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 14]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 14]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -837,7 +837,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 15]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 15]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -893,7 +893,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 16]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 16]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -949,7 +949,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 17]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 17]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -1005,7 +1005,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 18]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 18]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -1061,7 +1061,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 19]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 19]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -1117,7 +1117,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 20]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 20]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -1173,7 +1173,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 21]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 21]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -1229,7 +1229,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 22]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 22]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -1285,7 +1285,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 23]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 23]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -1341,7 +1341,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 24]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 24]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -1397,7 +1397,7 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 25]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 25]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
@@ -1438,116 +1438,36 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    CNAME record that references the centrally operated DANE-TA(2) RRset.
    If a particular server's key is compromised, its TLSA CNAME SHOULD be
    replaced with a DANE-EE(3) association until the certificate for the
    CNAME record that references the centrally operated DANE-TA(2) RRset.
    If a particular server's key is compromised, its TLSA CNAME SHOULD be
    replaced with a DANE-EE(3) association until the certificate for the
-   compromised key expires, at which point it can return to using CNAME
-   record.  If the central trust anchor is compromised, all servers need
-   to be issued new keys by a new TA, and a shared DANE-TA(2) TLSA RRset
-   needs to be published containing just the new TA.  SMTP servers
-   cannot expect broad SMTP client CRL or OCSP support.
+   compromised key expires, at which point it can return to using a
+   CNAME record.  If the central trust anchor is compromised, all
+   servers need to be issued new keys by a new TA, and an updated DANE-
+   TA(2) TLSA RRset needs to be published containing just the new TA.
+
+   SMTP servers cannot expect broad CRL or OCSP support from SMTP
+   clients.  As outlined above, with DANE, compromised server or trust
+   anchor keys can be "revoked" by removing them from the DNS without
+   the need for client-side support for OCSP or CRLs.
 
 5.  Digest algorithm agility
 
 
 5.  Digest algorithm agility
 
-   While [RFC6698] specifies multiple digest algorithms, it does not
-   specify a protocol by which the SMTP client and TLSA record publisher
-   can agree on the strongest shared algorithm.  Such a protocol would
-   allow the client and server to avoid exposure to any deprecated
 
 
 
 
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 26]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 26]
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 \f
 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
+   While [RFC6698] specifies multiple digest algorithms, it does not
+   specify a protocol by which the SMTP client and TLSA record publisher
+   can agree on the strongest shared algorithm.  Such a protocol would
+   allow the client and server to avoid exposure to any deprecated
    weaker algorithms that are published for compatibility with less
    weaker algorithms that are published for compatibility with less
-   capable clients, but should be ignored when possible.  We specify
-   such a protocol below.
-
-   Suppose that a DANE TLS client authenticating a TLS server considers
-   digest algorithm "BetterAlg" stronger than digest algorithm
-   "WorseAlg".  Suppose further that a server's TLSA RRset contains some
-   records with "BetterAlg" as the digest algorithm.  Finally, suppose
-   that for every raw public key or certificate object that is included
-   in the server's TLSA RRset in digest form, whenever that object
-   appears with algorithm "WorseAlg" with some usage and selector it
-   also appears with algorithm "BetterAlg" with the same usage and
-   selector.  In that case our client can safely ignore TLSA records
-   with the weaker algorithm "WorseAlg", because it suffices to check
-   the records with the stronger algorithm "BetterAlg".
-
-   Server operators MUST ensure that for any given usage and selector,
-   each object (certificate or public key), for which a digest
-   association exists in the TLSA RRset, is published with the SAME SET
-   of digest algorithms as all other objects that published with that
-   usage and selector.  In other words, for each usage and selector, the
-   records with non-zero matching types will correspond to on a cross-
-   product of a set of underlying objects and a fixed set of digest
-   algorithms that apply uniformly to all the objects.
-
-   To achieve digest algorithm agility, all published TLSA RRsets for
-   use with opportunistic DANE TLS for SMTP MUST conform to the above
-   requirements.  Then, for each combination of usage and selector, SMTP
-   clients can simply ignore all digest records except those that employ
-   the strongest digest algorithm.  The ordering of digest algorithms by
-   strength is not specified in advance, it is entirely up to the SMTP
-   client.  SMTP client implementations SHOULD make the digest algorithm
-   preference order configurable.  Only the future will tell which
-   algorithms might be weakened by new attacks and when.
-
-   Note, TLSA records with a matching type of Full(0), that publish the
-   full value of a certificate or public key object, play no role in
-   digest algorithm agility.  They neither trump the processing of
-   records that employ digests, nor are they ignored in the presence of
-   any records with a digest (i.e. non-zero) matching type.
-
-
-
-
-
-
-
-
-
-
-
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 27]
-\f
-Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
-
-
-   SMTP clients SHOULD use digest algorithm agility when processing the
-   DANE TLSA records of an SMTP server.  Algorithm agility is to be
-   applied after first discarding any unusable or malformed records
-   (unsupported digest algorithm, or incorrect digest length).  Thus,
-   for each usage and selector, the client SHOULD process only any
-   usable records with a matching type of Full(0) and the usable records
-   whose digest algorithm is believed to be the strongest among usable
-   records with the given usage and selector.
-
-   The main impact of this requirement is on key rotation, when the TLSA
-   RRset is pre-populated with digests of new certificates or public
-   keys, before these replace or augment their predecessors.  Were the
-   newly introduced RRs to include previously unused digest algorithms,
-   clients that employ this protocol could potentially ignore all the
-   digests corresponding to the current keys or certificates, causing
-   connectivity issues until the new keys or certificates are deployed.
-   Similarly, publishing new records with fewer digests could cause
-   problems for clients using cached TLSA RRsets that list both the old
-   and new objects once the new keys are deployed.
-
-   To avoid problems, server operators SHOULD apply the following
-   strategy:
-
-   o  When changing the set of objects published via the TLSA RRset
-      (e.g. during key rotation), DO NOT change the set of digest
-      algorithms used; change just the list of objects.
-
-   o  When changing the set of digest algorithms, change only the set of
-      algorithms, and generate a new RRset in which all the current
-      objects are re-published with the new set of digest algorithms.
-
-   After either of these two changes are made, the new TLSA RRset should
-   be left in place long enough that the older TLSA RRset can be flushed
-   from caches before making another change.
+   capable clients, but should be ignored when possible.  Such a
+   protocol is specified in [I-D.ietf-dane-ops].  SMTP clients and
+   servers that implement this specification MUST comply with the
+   requirements outlined under "Digest Algorithm Agility" in
+   [I-D.ietf-dane-ops].
 
 6.  Mandatory TLS Security
 
 
 6.  Mandatory TLS Security
 
@@ -1562,14 +1482,6 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    MX hostnames, a sending MTA can be configured to use the receiving
    domains's DANE TLSA records to authenticate the corresponding SMTP
    server.  Authentication via DANE TLSA records is easier to manage, as
    MX hostnames, a sending MTA can be configured to use the receiving
    domains's DANE TLSA records to authenticate the corresponding SMTP
    server.  Authentication via DANE TLSA records is easier to manage, as
-
-
-
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 28]
-\f
-Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
-
-
    changes in the receiver's expected certificate properties are made on
    the receiver end and don't require manually communicated
    configuration changes.  With mandatory DANE TLS, when no usable TLSA
    changes in the receiver's expected certificate properties are made on
    the receiver end and don't require manually communicated
    configuration changes.  With mandatory DANE TLS, when no usable TLSA
@@ -1595,6 +1507,13 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    replaced by corresponding DNS Service (SRV) records
    [I-D.ietf-dane-srv].
 
    replaced by corresponding DNS Service (SRV) records
    [I-D.ietf-dane-srv].
 
+
+
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 27]
+\f
+Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
+
+
    However, until MUAs begin to adopt the dynamic configuration
    mechanisms of [RFC6186] they are adequately served by more
    traditional static TLS security policies.  Specification of DANE TLS
    However, until MUAs begin to adopt the dynamic configuration
    mechanisms of [RFC6186] they are adequately served by more
    traditional static TLS security policies.  Specification of DANE TLS
@@ -1618,14 +1537,6 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    Each SMTP server MUST present a certificate chain (see [RFC5246]
    Section 7.4.2) that matches at least one of the TLSA records.  The
    server MAY rely on SNI to determine which certificate chain to
    Each SMTP server MUST present a certificate chain (see [RFC5246]
    Section 7.4.2) that matches at least one of the TLSA records.  The
    server MAY rely on SNI to determine which certificate chain to
-
-
-
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 29]
-\f
-Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
-
-
    present to the client.  Clients that don't send SNI information may
    not see the expected certificate chain.
 
    present to the client.  Clients that don't send SNI information may
    not see the expected certificate chain.
 
@@ -1651,6 +1562,14 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    offer to negotiate a typical set of non-anonymous cipher suites
    required for interoperability with such servers.  An SMTP client
    employing pre-DANE opportunistic TLS MAY in addition include one or
    offer to negotiate a typical set of non-anonymous cipher suites
    required for interoperability with such servers.  An SMTP client
    employing pre-DANE opportunistic TLS MAY in addition include one or
+
+
+
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 28]
+\f
+Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
+
+
    more anonymous TLS cipher suites in its TLS HELLO.  SMTP servers,
    that need to interoperate with opportunistic TLS clients SHOULD be
    prepared to interoperate with such clients by either always selecting
    more anonymous TLS cipher suites in its TLS HELLO.  SMTP servers,
    that need to interoperate with opportunistic TLS clients SHOULD be
    prepared to interoperate with such clients by either always selecting
@@ -1674,14 +1593,6 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    failure to deliver time-sensitive email.  The sending MTA
    administrator may have to choose between letting email queue until
    the error is resolved and disabling opportunistic or mandatory DANE
    failure to deliver time-sensitive email.  The sending MTA
    administrator may have to choose between letting email queue until
    the error is resolved and disabling opportunistic or mandatory DANE
-
-
-
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 30]
-\f
-Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
-
-
    TLS for one or more destinations.  The choice to disable DANE TLS
    security should not be made lightly.  Every reasonable effort should
    be made to determine that problems with mail delivery are the result
    TLS for one or more destinations.  The choice to disable DANE TLS
    security should not be made lightly.  Every reasonable effort should
    be made to determine that problems with mail delivery are the result
@@ -1702,6 +1613,19 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    least one TLSA record when usable TLSA records are found for that
    server.
 
    least one TLSA record when usable TLSA records are found for that
    server.
 
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 29]
+\f
+Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
+
+
 9.2.  Publisher Operational Considerations
 
    SMTP servers that publish certificate usage DANE-TA(2) associations
 9.2.  Publisher Operational Considerations
 
    SMTP servers that publish certificate usage DANE-TA(2) associations
@@ -1709,13 +1633,11 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    chain, even when that TA certificate is a self-signed root
    certificate.
 
    chain, even when that TA certificate is a self-signed root
    certificate.
 
-   TLSA Publishers MUST follow the digest agility guidelines in
-   Section 5 and MUST make sure that all objects published in digest
-   form for a particular usage and selector are published with the same
-   set of digest algorithms.
+   TLSA Publishers MUST follow the guidelines in the "TLSA Publisher
+   Requirements" section of [I-D.ietf-dane-ops].
 
 
-   TLSA Publishers should follow the TLSA publication size guidance
-   found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines".
+   TLSA Publishers SHOULD follow the TLSA publication size guidance
+   found in [I-D.ietf-dane-ops] under "DANE DNS Record Size Guidelines".
 
 10.  Security Considerations
 
 
 10.  Security Considerations
 
@@ -1726,18 +1648,6 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    sending MTAs to securely discover both the availability of TLS and
    how to authenticate the destination.
 
    sending MTAs to securely discover both the availability of TLS and
    how to authenticate the destination.
 
-
-
-
-
-
-
-
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 31]
-\f
-Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
-
-
    This protocol does not aim to secure all SMTP traffic, as that is not
    practical until DNSSEC and DANE adoption are universal.  The
    incremental deployment provided by following this specification is a
    This protocol does not aim to secure all SMTP traffic, as that is not
    practical until DNSSEC and DANE adoption are universal.  The
    incremental deployment provided by following this specification is a
@@ -1764,6 +1674,14 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    specification that indicate when it is appropriate to initiate a non-
    authenticated connection or cleartext connection to a SMTP server.
    Specifically, in order to prevent downgrade attacks on this protocol,
    specification that indicate when it is appropriate to initiate a non-
    authenticated connection or cleartext connection to a SMTP server.
    Specifically, in order to prevent downgrade attacks on this protocol,
+
+
+
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 30]
+\f
+Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
+
+
    implementation must not initiate a connection when this specification
    indicates a particular SMTP server must be considered unreachable.
 
    implementation must not initiate a connection when this specification
    indicates a particular SMTP server must be considered unreachable.
 
@@ -1786,22 +1704,14 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    Postfix, and whose advice and feedback were essential to the
    development of the Postfix DANE implementation.
 
    Postfix, and whose advice and feedback were essential to the
    development of the Postfix DANE implementation.
 
-
-
-
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 32]
-\f
-Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
-
-
 13.  References
 
 13.1.  Normative References
 
    [I-D.ietf-dane-ops]
 13.  References
 
 13.1.  Normative References
 
    [I-D.ietf-dane-ops]
-              Dukhovni, V. and W. Hardaker, "DANE TLSA implementation
-              and operational guidance", draft-ietf-dane-ops-00 (work in
-              progress), October 2013.
+              Dukhovni, V. and W. Hardaker, "Updates to and Operational
+              Guidance for the DANE Protocol", draft-ietf-dane-ops-06
+              (work in progress), August 2014.
 
    [RFC1035]  Mockapetris, P., "Domain names - implementation and
               specification", STD 13, RFC 1035, November 1987.
 
    [RFC1035]  Mockapetris, P., "Domain names - implementation and
               specification", STD 13, RFC 1035, November 1987.
@@ -1820,6 +1730,14 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
               Rose, "Resource Records for the DNS Security Extensions",
               RFC 4034, March 2005.
 
               Rose, "Resource Records for the DNS Security Extensions",
               RFC 4034, March 2005.
 
+
+
+
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 31]
+\f
+Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
+
+
    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "Protocol Modifications for the DNS Security
               Extensions", RFC 4035, March 2005.
    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "Protocol Modifications for the DNS Security
               Extensions", RFC 4035, March 2005.
@@ -1838,18 +1756,6 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
    [RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
               Extension Definitions", RFC 6066, January 2011.
 
    [RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
               Extension Definitions", RFC 6066, January 2011.
 
-
-
-
-
-
-
-
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 33]
-\f
-Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
-
-
    [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
               Verification of Domain-Based Application Service Identity
               within Internet Public Key Infrastructure Using X.509
    [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
               Verification of Domain-Based Application Service Identity
               within Internet Public Key Infrastructure Using X.509
@@ -1879,32 +1785,32 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 13.2.  Informative References
 
    [I-D.dukhovni-opportunistic-security]
 13.2.  Informative References
 
    [I-D.dukhovni-opportunistic-security]
-              Dukhovni, V., "Opportunistic Security: some protection
-              most of the time", draft-dukhovni-opportunistic-
-              security-01 (work in progress), July 2014.
-
-   [I-D.ietf-dane-srv]
-              Finch, T., "Using DNS-Based Authentication of Named
-              Entities (DANE) TLSA records with SRV and MX records.",
-              draft-ietf-dane-srv-02 (work in progress), February 2013.
 
 
-   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598, July
-              2009.
 
 
-   [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
-              STD 72, RFC 6409, November 2011.
 
 
-Authors' Addresses
 
 
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 32]
+\f
+Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
+              Dukhovni, V., "Opportunistic Security: Some Protection
+              Most of the Time", draft-dukhovni-opportunistic-
+              security-03 (work in progress), August 2014.
 
 
+   [I-D.ietf-dane-srv]
+              Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
+              Based Authentication of Named Entities (DANE) TLSA Records
+              with SRV Records", draft-ietf-dane-srv-07 (work in
+              progress), July 2014.
 
 
+   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598, July
+              2009.
 
 
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 34]
-\f
-Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
+   [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
+              STD 72, RFC 6409, November 2011.
 
 
+Authors' Addresses
 
    Viktor Dukhovni
    Two Sigma
 
    Viktor Dukhovni
    Two Sigma
@@ -1939,22 +1845,4 @@ Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
 
 
 
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dukhovni & Hardaker     Expires February 3, 2015               [Page 35]
+Dukhovni & Hardaker     Expires February 18, 2015              [Page 33]