Re: UTA: Server certificate management (Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt>)

[Harald Alvestrand <[e-mail]>]

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.