[dane] Further off-list feedback on SMTP draft

Viktor Dukhovni <viktor1dane@dukhovni.org> Sun, 16 February 2014 21:50 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 04CFB1A02B0 for <dane@ietfa.amsl.com>; Sun, 16 Feb 2014 13:50:23 -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 ffNraNACujiD for <dane@ietfa.amsl.com>; Sun, 16 Feb 2014 13:50:21 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id CC2631A021E for <dane@ietf.org>; Sun, 16 Feb 2014 13:50:20 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3A6EE2AB254; Sun, 16 Feb 2014 21:50:18 +0000 (UTC)
Date: Sun, 16 Feb 2014 21:50:18 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140216215017.GE278@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/WzsSFwo_qmc8teoMKv6yOu_cVz4
Subject: [dane] Further off-list feedback on SMTP draft
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:50:23 -0000

Wietse also (correctly IMHO) suggest that the discussion of possible
applicability to MUA DANE SMTP needlessly dominates the introduction.

The corresponding change in the organization of the document is to
move the short MUA discussion to its own small section in the
document, and simply reference it briefly in the introduction.

diff --git a/draft-ietf-dane-smtp-with-dane-08.xml b/draft-ietf-dane-smtp-with-dane-08.xml
index bdce22c..066f3e7 100644
--- a/draft-ietf-dane-smtp-with-dane-08.xml
+++ b/draft-ietf-dane-smtp-with-dane-08.xml
@@ -91,22 +91,9 @@ generally opportunistic.
 <t>
-We note that the SMTP protocol is also used between Message User
-Agents (MUAs) and Message Submission Agents (MSAs) <xref
-target="RFC6409" />.  In <xref target="RFC6186"/> a protocol is
-specified that enables an MUA to dynamically locate the MSA based on
-the user's email address.  SMTP connection security requirements for
-MUAs implementing <xref target="RFC6186"/> are largely analogous to
-connection security requirements for MTAs, and this specification
-could be applied largely verbatim with DNS MX records replaced by
-corresponding DNS Service (SRV) records <xref
-target="I-D.ietf-dane-srv" />.
-</t>
-
-<t>
-However, until MUAs begin to adopt the dynamic configuration
-mechanisms of <xref target="RFC6186"/> they are adequately served
-by more traditional static TLS security policies.  This document will not
-discuss the MUA use case further, leaving specification
-of DANE TLS for MUAs to future documents that focus specifically
-on SMTP security between MUAs and MSAs.  The rest of this memo will
-focus on securing MTA to MTA SMTP connections.
+Problems with existing use of TLS in MTA to MTA SMTP that motivate
+this specification are described in <xref target="channelsecurity"/>.
+The specification itself follows in <xref target="specification"/>.
+Then, in <xref target="mandatory"/>, we discuss application of DANE
+TLS to destinations for which channel integrity and confidentiality
+are mandatory.  In <xref target="mua"/> we briefly comment on
+potential applicability of this specification to Message User Agents.
 </t>
@@ -1519,2 +1506,27 @@ or misconfigures SMTP server certificate chains, mail will be delayed.
 
+<section title="Note on DANE for Message User Agents" anchor="mua">
+
+<t>
+We note that the SMTP protocol is also used between Message User
+Agents (MUAs) and Message Submission Agents (MSAs) <xref
+target="RFC6409"/>.  In <xref target="RFC6186"/> a protocol is
+specified that enables an MUA to dynamically locate the MSA based on
+the user's email address.  SMTP connection security considerations for
+MUAs implementing <xref target="RFC6186"/> are largely analogous to
+connection security requirements for MTAs, and this specification
+could be applied largely verbatim with DNS MX records replaced by
+corresponding DNS Service (SRV) records <xref target="I-D.ietf-dane-srv"/>.
+</t>
+
+<t>
+However, until MUAs begin to adopt the dynamic configuration
+mechanisms of <xref target="RFC6186"/> they are adequately served
+by more traditional static TLS security policies.  Specification
+of DANE TLS for Message User Agent (MUA) to Message Submission Agent
+(MSA) SMTP is left to future documents that focus specifically on
+SMTP security between MUAs and MSAs.
+</t>
+
+</section><!-- Note on DANE for MUAs -->
+
 <section anchor="Operational" title="Operational Considerations">

-- 
	Viktor.