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

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 16 Feb 2014 21:50:18 +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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Feb 2014 02:36:04 +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.