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

From: [email-masked]
Date: Wed, 09 Dec 2015 09:26:38 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Using TLS in Applications Working Group of the IETF.

        Title           : Updated TLS Server Identity Check Procedure for Email Related Protocols
        Author          : Alexey Melnikov
	Filename        : draft-ietf-uta-email-tls-certs-07.txt
	Pages           : 11
	Date            : 2015-12-09

Abstract:
   This document describes TLS server identity verification procedure
   for SMTP Submission, IMAP, POP and ManageSieve clients.  It replaces
   Section 2.4 of RFC 2595, updates Section 4.1 of RFC 3207, updates
   Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804.

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

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Dec 2015 17:29:43 +0000

Hi,

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

Best Regards,
Alexey

---

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

> 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: Leif Johansson <[email-masked]>
Date: Tue, 15 Dec 2015 09:55:47 +0100

> not everyone might have seen it.

Victor - your criticism may be warranted (I don't have a personal
opinion however) but it is very hard for Alexei to do anything
about unless you or somebody help by making your comments more
specific

	Thx!

	Leif

---

From: "John Levine" <[email-masked]>
Date: 15 Dec 2015 21:05:39 -0000

>5.1.  Notes on hosting multiple domains

The multiple domain stuff still needs work, and there seems to be
confusion between the domain name of the server (CN or SRV-ID) and the
domain name(s) for the mail it handles (DNS-ID.)  In nearly every case
the server and the mail will have different domain names, usually with
no lexical connection, e.g. a zillion little hosted mail domains all
pick up their mail from imap.gmail.com.

The SNI discussion is wrong because SNI only affects CN or SRV-ID, and
anyway at the time the TLS connection is made, the client can tell the
server the name of the server it wants, e.g. imap.gmail.com, but not
the domain of the mail it's planning to pick up, since the first place
the mail domain is mentioned is the login which happens after the TLS
session is set up.

Separate domain names and SNI could work if there's a separate server
name per mail domain all pointing at the same server, e.g.
smallco.biz.imap.gmail.com, but that scales poorly, and there's still
no way for a CA to sign it since there's no way for a CA to tell what
mail domains go with which servers.  It's pretty ugly, too.

I suggest taking out most of the multiple domain stuff and say that there's
currently no automated way to match mail domain to server domain in other
than a few special cases, and it needs more standards work, like telling
people to use DNSSEC+RFC 6186.

R's,
John