Subject: Re: [Uta] I-D Action: draft-ietf-uta-email-tls-certs-07.txt

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Dec 2015 16:44:50 +0000

On Wed, Dec 09, 2015 at 05:29:43PM +0000, Alexey Melnikov wrote:

> On 09/12/2015 17:26, [email-masked] wrote:
> >The IETF datatracker status page for this draft is:
> >https://datatracker.ietf.org/doc/draft-ietf-uta-email-tls-certs/
> >
> >There's also a htmlized version available at:
> >https://tools.ietf.org/html/draft-ietf-uta-email-tls-certs-07
> >
> >A diff from the previous version is available at:
> >https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-email-tls-certs-07
> In this version I've added 2 sections:
> 
> 4.1.  Notes on handling of SRV-ID by Certification Authorities
> 5.1.  Notes on hosting multiple domains
> 
> discussing remaining issues raised during the IETF LC.

I don't think this adequately addresses the recent discussion
(the text also seems rushed, and requires much polish).

--
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Dec 2015 17:30:27 +0000

Victor,

> On 14 Dec 2015, at 16:44, Viktor Dukhovni <[email-masked]> wrote:
> 

I suggest you help with some specific text or suggested changes.

Thank you,
Alexey

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Dec 2015 17:24:59 +0000

> I suggest you help with some specific text or suggested changes.

I might be able to do that, but not immediately or definitely.
Cycle-starved right now, trying to complete DANE support for the
next OpenSSL 1.1.0 alpha release.  I am hoping some of the other
participants from the earlier discussion via [email-masked] will
respond, as the new version notice only went to the UTA list, where
not everyone might have seen it.

-- 
	Viktor.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 16 Dec 2015 19:26:44 +0100

> 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>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Dec 2015 12:04:50 +0000

Hi Alessandro,

> I attach a tentative wording
Thank you, I used most of your text (and extended it a bit).