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.