Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-07.txt

From: [email-masked]
Date: Fri, 14 Feb 2014 09:18:36 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

        Title           : SMTP security via opportunistic DANE TLS
        Authors         : Viktor Dukhovni
                          Wes Hardaker
	Filename        : draft-ietf-dane-smtp-with-dane-07.txt
	Pages           : 29
	Date            : 2014-02-14

Abstract:
   This memo describes a downgrade-resistant protocol for SMTP transport
   security between Mail Transfer Agents (MTAs) based on the DNS-Based
   Authentication of Named Entities (DANE) TLSA DNS record.  Adoption of
   this protocol enables an incremental transition of the Internet email
   backbone to one using encrypted and authenticated Transport Layer
   Security (TLS).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 14 Feb 2014 09:31:16 -0800

>  Entities Working Group of the IETF.

The only changes in this version are fixes for idnits and cleaning up of
the required references.
-- 
Wes Hardaker
Parsons

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 16 Feb 2014 21:41:54 +0000

> The only changes in this version are fixes for idnits and cleaning up of

While the document is frozen for last-call and prior to the London
meeting, I am staging changes based on feedback.

Some of that feedback is off-list.  In particular Wietse Venema
sent review comments.  I am posting the corresponding revisions to
the list, if there are any objections, please speak up.

The first set of staged changes is:

    * Fix title of section "2.", it is not about hardening (pre-DANE)
      opportunistc TLS, rather it specifies opportunistic DANE TLS.

    * Add a termilogy entry for MITM.

    * Fix hyphenation of qualifiers (e.g. high value -> high-value) and
      a typo or two.

    * Clarify claim that DANE authentication with input from server
      might be more reliable than authentication with no server provided
      parameters.

diff --git a/draft-ietf-dane-smtp-with-dane-08.xml b/draft-ietf-dane-smtp-with-dane-08.xml
index 3e36496..bdce22c 100644
--- a/draft-ietf-dane-smtp-with-dane-08.xml
+++ b/draft-ietf-dane-smtp-with-dane-08.xml
@@ -129,2 +129,6 @@ The following terms or concepts are used through the document:
 
+    <t hangText="Man-in-the-middle or MITM attack:">
+    Active modification of network traffic by an adversary able to
+    thereby compromise the confidentiality or integrity of the data.  </t>
+
     <t hangText="secure, bogus, insecure, indeterminate:">
@@ -253,4 +257,3 @@ authentication, TLS provides only privacy protection against
 eavesdropping attacks.  With authentication, TLS also provides data
-integrity protection to guard against man-in-the-middle (MITM)
-attacks.
+integrity protection to guard against MITM attacks.
 </t>
@@ -310,6 +313,6 @@ the client also supports TLS, it may negotiate a TLS encrypted
 channel to use for email transmission.  The server's indication of
-TLS support can be easily suppressed by a man in the middle attacker.
+TLS support can be easily suppressed by an MITM attacker.
 Thus pre-DANE SMTP TLS security can be subverted by simply downgrading
 a connection to cleartext.  No TLS security feature, such as the
-use of PKIX, can prevent this.  The attacker can simply bypass TLS.
+use of PKIX, can prevent this.  The attacker can simply disable TLS.
 </t>
@@ -328,3 +331,3 @@ domain.
 <t>
-A PKIX TLS client is vulnerable to man in the middle (MITM) attacks
+A PKIX TLS client is vulnerable to MITM attacks
 unless it verifies that the server's certificate binds its public
@@ -365,3 +368,3 @@ more.  Adding any other trusted actors to the mix can only reduce
 SMTP security.  A sender may choose to harden DNSSEC for selected
-high value receiving domains, by configuring explicit trust anchors
+high-value receiving domains, by configuring explicit trust anchors
 for those domains instead of relying on the chain of trust from the
@@ -431,3 +434,3 @@ inclusive enough.
 
-<section title="Hardening (pre-DANE) Opportunistic TLS">
+<section title="Opportunistic DANE TLS" anchor="specification">
 
@@ -519,3 +522,2 @@ DNS resolver MUST be able to determine whether a given non-error
 DNS response is "secure", "insecure", "bogus" or "indeterminate".
-<!-- XXXWJH: -->
 It is expected that most security-aware stub resolvers will not
@@ -730,3 +732,3 @@ than a DNS domain, DANE TLS does not apply.  Delivery proceeds using
 any relevant security policy configured by the MTA administrator.
-Similarly, when an MX RRset incorrectly lists an network address in lieu
+Similarly, when an MX RRset incorrectly lists a network address in lieu
 of an MX hostname, if the MTA chooses to connect to the network address
@@ -759,3 +761,3 @@ that has no TLSA records.  In other words, prevention of delivery
 loops by obeying MX preferences MUST take precedence over channel
-security considerations.  Even with two equal preference MX records, an MTA
+security considerations.  Even with two equal-preference MX records, an MTA
 is not obligated to choose the MX hostname that offers more security.
@@ -817,3 +819,3 @@ administrator to handle some or all mail. </t>
 no MX records.  In this case the domain's name is implicitly also
-the hostname of its sole SMTP server. </t>
+its sole SMTP server name. </t>
 
@@ -1036,4 +1038,5 @@ implied by the presence of DANE TLSA records and the verification
 parameters necessary to authenticate the TLS peer are obtained
-together, therefore authentication via this protocol is expected
-to be less prone to connection failure caused by incompatible
+together.  In contrast to protocols where channel security policy
+is set exclusively by the client, authentication via this protocol
+is expected to be less prone to connection failure caused by incompatible
 configuration of the client and server.

-- 
	Viktor.