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

[Viktor Dukhovni <[e-mail]>]

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.