Re: [dane] Further off-list feedback on SMTP draft

Viktor Dukhovni <viktor1dane@dukhovni.org> Mon, 17 February 2014 02:36 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 303001A01D1 for <dane@ietfa.amsl.com>; Sun, 16 Feb 2014 18:36:11 -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 m8GN3MGuwpJf for <dane@ietfa.amsl.com>; Sun, 16 Feb 2014 18:36:08 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9601A005F for <dane@ietf.org>; Sun, 16 Feb 2014 18:36:07 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D057D2AB254; Mon, 17 Feb 2014 02:36:04 +0000 (UTC)
Date: Mon, 17 Feb 2014 02:36:04 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140217023604.GF278@mournblade.imrryr.org>
References: <20140216215017.GE278@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140216215017.GE278@mournblade.imrryr.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/rVewBinUIlFeRPzoWYoJkMFxWTo
Subject: Re: [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: Mon, 17 Feb 2014 02:36:11 -0000

On Sun, Feb 16, 2014 at 09:50:18PM +0000, Viktor Dukhovni wrote:

In addition Wietse's comments on Section 2.3.1, suggest a change
in organization with a move of key rotation discussion to its own
section.

NOTE: The discussion of DANE-TA(2) was updated to recommend a
selector of Cert(0).  Earlier conversion of the document from bare
numbers to the new acronyms introduced an error changing "2 1 1 or
2 0 1" to "2 1 1 or 2 1 0".  While fixing that inadvertent error,
I took the opportunity to note that with DANE-TA(2) associations
it best to specify the whole certificate, not just the public key.

--- a/draft-ietf-dane-smtp-with-dane-08.xml
+++ b/draft-ietf-dane-smtp-with-dane-08.xml
@@ -1088,2 +1088,12 @@ or public key, and likewise SHA2-512(2) means a SHA2-512 digest is used.
 <t>
+Since opportunistic DANE TLS will be used by non-interactive MTAs,
+with no user to "press OK" when authentication fails, reliability
+of peer authentication is paramount.  Server operators are advised
+to publish TLSA records that are least likely to fail authentication
+due to interoperability or operational problems.  Because DANE TLS
+relies on coordinated changes to DNS and SMTP server settings, the
+best choice of records to publish will depend on site-specific practices.
+</t>
+
+<t>
 The certificate usage element of a TLSA record plays a critical
@@ -1100,8 +1110,2 @@ with opportunistic DANE TLS.
 <t>
-Since opportunistic DANE TLS will be used by non-interactive MTAs,
-with no user to "press OK" when authentication fails, reliability
-of peer authentication is paramount.  
-</t>
-
-<t>
 Authentication via certificate usage DANE-EE(3) TLSA records involves
@@ -1118,11 +1122,9 @@ when the TLSA record matches the server's default certificate).
 <t>
-Two TLSA records MUST be published before updating a server's
-public key, one matching the currently deployed key and the other
-matching the new key scheduled to replace it.  Once sufficient time
-has elapsed for all DNS caches to expire the previous TLSA RRset and
-related signature RRsets, the server may be reconfigured to
-use the new private key and associated public key certificate.  Once
-the server is using the new key, the TLSA RR that matches the retired
-key can be removed from DNS, leaving only the RR that matches the
-new key.
+For domains where it is practical to make coordinated changes in
+DNS TLSA records during SMTP server key rotation, it is often best
+to publish end-entity DANE-EE(3) certificate associations.  DANE-EE(3)
+certificates don't suddenly stop working when leaf or intermediate
+certificates expire, and don't fail when the server operator
+neglects to configure all the required issuer certificates in the
+server certificate chain.
 </t>
@@ -1131,6 +1133,5 @@ new key.
 TLSA records published for SMTP servers SHOULD, in most cases, be
-"DANE-EE(3) SPKI(1) SHA2-256(1)" records. 
-Since all DANE implementations are required to support SHA2-256,
-this record works for all clients and need not change across
-certificate renewals with the same key.
+"DANE-EE(3) SPKI(1) SHA2-256(1)" records.  Since all DANE implementations
+are required to support SHA2-256, this record type works for all clients
+and need not change across certificate renewals with the same key.
 </t>
@@ -1168,7 +1169,17 @@ in the TLS server certificate message.
 <t>
-TLSA Publishers should publish either "DANE-TA(2) SPKI(1) Full(0)" or
-"DANE-TA(2) Cert(0) SHA2-256(1)" TLSA parameters.
-As with leaf certificate rollover discussed in <xref
-target="cert3" />, two such TLSA RRs need to be published to
-facilitate TA certificate rollover.
+TLSA Publishers employing DANE-TA(2) records SHOULD publish records
+with a selector of Cert(0).  Such TLSA records are associated with
+the whole trust anchor certificate, not just with the trust anchor
+public key.  In particular, the SMTP client SHOULD then apply any
+relevant constraints from the trust anchor certificate, such as,
+for example, path length constraints.
+</t>
+
+<t>
+While a selector of SPKI(1) may also be employed, the resulting
+TLSA record will not specify the full trust anchor certificate
+content, and elements of the trust anchor certificate other than
+the public key become mutable.  This may, for example, allow a
+subsidiary CA to issue a chain that violates the trust anchor's
+path length or name constraints.
 </t>
@@ -1365,2 +1376,22 @@ care to authenticate the server.
 
+<section title="Key rotation" anchor="rotation">
+
+<t>
+Two TLSA records MUST be published before employing a new EE or TA
+public key or certificate, one matching the currently deployed key
+and the other matching the new key scheduled to replace it.  Once
+sufficient time has elapsed for all DNS caches to expire the previous
+TLSA RRset and related signature RRsets, servers may be configured
+to use the new EE private key and associated public key certificate
+or may employ certificates signed by the new trust anchor.
+</t>
+
+<t>
+Once the new public key or certificate is in use, the TLSA RR that
+matches the retired key can be removed from DNS, leaving only RRs
+that match keys or certificates in active use.
+</t>
+
+</section><!-- Key rotation -->
+
 <section title="Digest algorithm agility" anchor="agility">

-- 
	Viktor.