Re: [dane] WGLC: DANE-SMTP (final operational guidance tweaks?)

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 28 February 2015 21:48 UTC

Return-Path: <ietf-dane@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 417F01A001B for <dane@ietfa.amsl.com>; Sat, 28 Feb 2015 13:48:31 -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 00WHrSMxytYH for <dane@ietfa.amsl.com>; Sat, 28 Feb 2015 13:48:29 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126C51A001A for <dane@ietf.org>; Sat, 28 Feb 2015 13:48:28 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B85C9282FC2; Sat, 28 Feb 2015 21:48:27 +0000 (UTC)
Date: Sat, 28 Feb 2015 21:48:27 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: "<dane@ietf.org>" <dane@ietf.org>
Message-ID: <20150228214827.GA1260@mournblade.imrryr.org>
References: <20141209095813.GP285@mournblade.imrryr.org> <20150108011529.GU7322@mournblade.imrryr.org> <18B6C626-B27B-4EE9-A3E2-32CD43B195FA@ogud.com> <20150220220921.GH1260@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20150220220921.GH1260@mournblade.imrryr.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/ejl8zlGLHtiVZ8yaFP7b_ZaPdAI>
Subject: Re: [dane] WGLC: DANE-SMTP (final operational guidance tweaks?)
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: Sat, 28 Feb 2015 21:48:31 -0000

On Fri, Feb 20, 2015 at 10:09:21PM +0000, Viktor Dukhovni wrote:

> > The github repository contains a version of the document that addresses
> > all the comments received.  Editors please post ASAP.
> 
> A -14 version has been pushed.  I've not yet received any feedback on
> the possibility of extending the operational considerations section
> based on the last few months of operational experience.  Please
> advise...

Perhaps making this more concrete will help.  I can publish a -15
with the following changes:

    * In Publisher Operational considerations again mention the need to avoid
      PKIX-TA/PKIX-EE 

    * In Publisher Operational considerations note that DANE TLSA and
      MTAs that only offer STARTTLS selectively (e.g. to client that
      pass greylisting) don't mix.

    * Note that some software cannot send root trust-anchors, if so
      the server TLSA records need to list an intermediate CA or use
      DANE-EE(3).

    * In section 3.1.3 note that the SHOULD NOT for PKIX-TA/PKIX-EE
      applies only to MTA-to-MTA SMTP, and MUA-to-MSA is not in scope.

FYI, the current main culprit for selective STARTTLS is "spamd",
and its authors are reputedly working on STARTTLS support to address
the issue!  The software simply had no STARTTLS support, and handles
the first transaction with a new client before allowing connections
to the real MTA.  There was no intention to specifically deny TLS
to new clients.

As for inability to send the root CA, reportedly that's an issue
with Microsoft Exchange, where either the Exchange software or
Schannel or both cannot be configured to put the root CA cert on
the wire.  Have not tried this myself.

The XML diff is below my signature.  Most of the operational issues
over the last few month are not SMTP specific, and the corresponding
operational guidace will be added to the OPS draft.

Should I add these to -15 before IETF LC?

-- 
	Viktor.

diff --git a/draft-ietf-dane-smtp-with-dane b/draft-ietf-dane-smtp-with-dane
index 55d6be3..60eff9e 100644
--- a/draft-ietf-dane-smtp-with-dane
+++ b/draft-ietf-dane-smtp-with-dane
@@ -1311,10 +1311,20 @@ path length or name constraints.
 
 </section><!-- Certificate usage 2 -->
 
-<section title="Certificate usages PKIX-TA(0) and PKIX-EE(1)">
+<section title="Certificate usages PKIX-TA(0) and PKIX-EE(1)" anchor="pkix-usages">
 
+<t>
+Note, this section applies to MTA-to-MTA SMTP on port 25.  That is,
+to servers that are the SMTP servers for one or more destination
+domains.  Other uses of SMTP, such as in MUA-to-MSA submission on
+ports 587 or 465 are out of scope for this document.  Where those
+other uses also employ TLS opportunistically and/or depend on DNSSEC
+as a result of DNS-based discovery of service location, the relevant
+specifications should, as appropriate, arrive at similar conclusions.
+</t>
+
 <t>
-As noted in the introduction, SMTP clients cannot, without relying
+As noted in the introduction, sending MTAs cannot, without relying
 on DNSSEC for secure MX records and DANE for STARTTLS support
 signaling, perform server identity verification or prevent STARTTLS
 downgrade attacks.  The use of PKIX CAs offers no added security
@@ -1324,12 +1334,13 @@ convenient non-PKIX certificate usage.
 </t>
 
 <t>
-SMTP servers SHOULD NOT publish TLSA RRs with certificate usage
-PKIX-TA(0) or PKIX-EE(1).  SMTP clients cannot be expected to be
-configured with a suitably complete set of trusted public CAs.
-Lacking a complete set of public CAs, clients would not be able to
-verify the certificates of SMTP servers whose issuing root CAs are
-not trusted by the client.
+Therefore, TLSA records for the port 25 SMTP service used by client
+MTAs SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0)
+or PKIX-EE(1).  SMTP client MTAs cannot be expected to be configured
+with a suitably complete set of trusted public CAs.  Lacking a
+complete set of public CAs, MTA clients would not be able to verify the
+certificates of SMTP servers whose issuing root CAs are not trusted
+by the client.
 </t>
 
 <t>
@@ -1734,10 +1745,31 @@ that server.
 <section anchor="oppublishers" title="Publisher Operational Considerations">
 
 <t>
+As explained in <xref target="pkix-usages"/> server operators SHOULD
+NOT publish TLSA records for their MTAs (port 25 SMTP) with certificate
+usages PKIX-TA(0) or PKIX-EE(1).
+</t>
+
+<t>
+Some MTAs enable STARTTLS selectively.  For example they might only
+support STARTTLS with clients that have previously demonstrated
+"proper MTA behaviour", for example by retrying the delivery of
+deferred messages (greylisting).  If such an MTA publishes DANE
+TLSA records, sending MTAs that implement this specification will
+not attempt the initial cleartext SMTP transaction needed to
+establish the "proper MTA behaviour", because they cannot establish
+the required channel security.  Server operators MUST NOT implement
+selective STARTTLS if they also want to support DANE TLSA.
+</t>
+
+<t>
 SMTP servers that publish certificate usage DANE-TA(2)
 associations MUST include the TA certificate in their TLS server
 certificate chain, even when that TA certificate is a self-signed
-root certificate.
+root certificate.  With some SMTP server software it is not possible to
+include root CA certificates in the server chain.  Such servers need to
+either publish DANE-TA(2) records for an intermediate certificate or
+to use DANE-EE(3).
 </t>
 
 <t>