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

[Viktor Dukhovni <[e-mail]>]

On Fri, Feb 14, 2014 at 09:31:16AM -0800, Wes Hardaker wrote:

> > 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.
> 
> The only changes in this version are fixes for idnits and cleaning up of
> the required references.

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.