Den 03. des. 2015 15:33, skrev Viktor Dukhovni:
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.
OK, make the use of "domain name from user's email address" and RFC 6186
support an experimental feature, perhaps described in an appendix. What
I want the document to call out is that there are known, important use
cases for which RFC 6186 together with this draft *DOES NOT WORK*.
Quoting RFC 2026 is always fun:
A Proposed Standard should have no known technical omissions with
respect to the requirements placed upon it. However, the IESG may
waive this requirement in order to allow a specification to advance
to the Proposed Standard state when it is considered to be useful and
necessary (and timely) even with known technical omissions.
The "technical omission" here is "using 6186 together with mail servers
supporting a high number of domains is going to be painful, and this
document doesn't say how to solve it".
Fix that, or document it.
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).
I read the TLS draft. This is still a misrepresentation; TLS 1.3 won't
force anyone to use it - the higher level protocol *can*, however, do that.
I would absolutely support a revision to RFC 6186 that mandates use of SNI.
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.
Yes, if 6186 support is taken out of the draft, the problem goes away.
But at the moment, 6186 is in the draft.
Pick your poison.