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

Viktor Dukhovni <viktor1dane@dukhovni.org> Sun, 16 February 2014 21:42 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017321A02D2 for <dane@ietfa.amsl.com>; Sun, 16 Feb 2014 13:42:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_RpkKgzzl3k for <dane@ietfa.amsl.com>; Sun, 16 Feb 2014 13:41:59 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id AC1D31A02CD for <dane@ietf.org>; Sun, 16 Feb 2014 13:41:58 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2AA7F2AB254; Sun, 16 Feb 2014 21:41:54 +0000 (UTC)
Date: Sun, 16 Feb 2014 21:41:54 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140216214154.GD278@mournblade.imrryr.org>
References: <20140214171836.22671.11628.idtracker@ietfa.amsl.com> <0l7g8xvbx7.fsf@wjh.hardakers.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0l7g8xvbx7.fsf@wjh.hardakers.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/YSI8p-qSkUhhdz97nd4bS0TlYWI
Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-07.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Feb 2014 21:42:02 -0000

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.