On Thu, Dec 03, 2015 at 12:53:25PM +0100, Harald Alvestrand wrote:
My objections to the draft would be alleviated if the abstract was
changed to:
This document describes an experimental TLS server identity verification
procedure for SMTP Submission, IMAP, POP and ManageSieve clients that
is appropriate for mail servers that host a small number of domains
under a single administration.
This scope reduction is I think much too drastic. Firstly, because
the RFC 6186 use-case is not the only one under consideration.
Indeed if we're concerned about applicability, the draft's text
for the most important use-case of explicitly specified service
end-points (the vast majority of current practice) does not face
any new operational barriers.
While the client would now check for "SRV-ID" with the user email
domainpart in the server certificate, there is no obligation on
the server certificate to contain these, as the client will *also*
check for the DNS-ID of the explicitly specified server hostname.
Procedures that scale to servers that host a large number of domains are
for further study.
And so in this case, all is well, provided the users of said domains
all manually specify the provider's SMTP and IMAP servers. It is
only the attempt to support "zero conf" via 6186 + SRV-ID for the
source domain that runs into likely difficulties actually obtaining
such certificates, and lack of SNI signalling.
The lack of SNI is easily addressed, by requiring clients that
implement RFC 6186 to use SNI (indeed they'll some day have no
choice but to do that anyway with TLS 1.3).
And in the security considerations section:
Because of the lack of client identification of the target domain,
See above, this is a completely avoidable obstacle.
the email server certificate described in this document has to contain
the complete list of names that the client will be looking for. If
RFC 6186 is in use, this means that the mail server certificate will hold
a list of all domains served by this service.
Hence the conclusion is not valid.
This reveals information about
other customers of the service, which may not be a desirable result.
And this too becomes moot.
--
Viktor.