On Mon 14/Dec/2015 18:30:27 +0100 Alexey Melnikov wrote:
>
> I suggest you help with some specific text or suggested changes.
In Section 5.1, I'd explicitly insert a trivial case requiring manual
configuration.
In Section 8, then, there should be a clarification on the context where manual
"pinning" configuration occurs.
I attach a tentative wording
Ale
--- draft-ietf-uta-email-tls-certs-07.xml 2015-12-16 18:44:03.699822067 +0100
+++ draft-ietf-uta-email-tls-certs-07+.xml 2015-12-16 19:20:06.485309685 +0100
@@ -362,6 +362,13 @@
<list style='numbers'>
<t>
+ Use SRV records to redirect each hosted email service to a fixed domain,
+ deploy TLS certificate(s) for that single domain, and instruct users to
+ configure their clients with appropriate pinning (unless the SRV records
+ can always be obtained via DNSSEC).
+ </t>
+
+ <t>
Use a single TLS certificate that includes a complete list of all the domains
it is serving.
</t>
@@ -391,7 +398,7 @@
</t>
<t>
- Several Mail Service Providers host hundreds and even thousands of domain.
+ Several Mail Service Providers host hundreds and even thousands of domains.
This document, as well as its predecessors RFC 2595, RFC 3207, RFC 3501 and RFC 5804
don't address scaling issues caused by use of TLS in multi-tenanted environments.
<!--////Also talk about delegation with and without SRV-ID. Use of DNSSEC?-->
@@ -510,6 +517,19 @@
<!--///Actually, this is not true, unless PKIX is also subverted:
TLS Server Identity Check doesn't protect from compromise of DNS information (such as DNS cache poisoning)
-->
+ </t>
+
+ <t>
+ The security warning in Section 6.6.4 of <xref target='RFC6125'/> does not
+ apply to appropriately configured email services. In fact, that case considers
+ a different name appearing unexpectedly during a connection attempt. Section 7.1 of
+ <xref target='RFC6125'/> discusses the context in which pinning occurs.
+ A context which provides for obtaining the target server name(s) beforehand
+ via an additional, unrelated communication path, for example on printed configuration
+ instructions, is to be considered as secure as the weakest of the paths involved.
+ </t>
+
+ <t>
Future work in this area might benefit from integration with DANE <xref target="RFC6698"/>,
but it is not covered by this document.
</t>