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.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
