ietf
[Top] [All Lists]

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

2015-12-01 09:51:10
If I understand this draft correctly, the server will have to do one
more thing:

- Change its certificate to include a complete list of all the domains
it is serving, and have its CA sign off on that certificate.

That's how I read it too, and it's a problem for two reasons.

One is that large mail systems handle vast numbers of domains.  I wouldn't
be surprised if there were 100,000 small domains all pointed at Google's
servers.  That would make the certificate, ah, bulky.

The other is that there is no reasonable way for a CA to verify that
the list of mail domains in a certificate is correct, which means that
SNI wouldn't help.  For example, one of my customers quarteracre.net
has a few mailboxes at hostedemail.com.  The usual CA validation
wouldn't help, since there is nothing in the WHOIS for quarteracre.net
or any of the other stuff that CA's normally check that tell you where
their mail is.

But there's no need to put this in the cert since RFC 6186 already tells you:

;; QUESTION SECTION:
;_imaps._tcp.quarteracre.net.   IN      SRV

;; ANSWER SECTION:
_imaps._tcp.quarteracre.net. 3600 IN    SRV     1 1 993 mail.a.hostedemail.com.
_imaps._tcp.quarteracre.net. 3600 IN    RRSIG   SRV 8 4 3600 20160201000000 
20151201054531 36633 quarteracre.net. 
bCSLoiCnQcftwclKRbVXxP8c8nsX+TtgGpDCMQUR1AM+gjejgQ9bzU0v 
ZWKW44whg1mXwN79FwArNEZ/6/B77w4PVjvVBOWW6ZIhIq9AawIplUXU 
CdZ43dhNR/oVdFbp/g7H4h1U5+JJJWt4hqiCG7NEoRp7/jT0l4y4ndxW YBo=

My suggestion would be to remove the email domain SRV-IDs from the
certificates since they don't tell you anything useful, and to advise
clients to use SRV and DNSSEC to get the name of the server if they
want to be sure they have the right one.  I suppose the CA could make
the DNS checks, but that seems like a bad idea since certs are
typically signed once a year, and a large mail system will add and
drop client domains every day.

This does leave open the loophole that a domain can point at servers
that aren't expecting to handle its mail, but we've had that problem
since MX records were invented.  The usual advice is "don't do that."

R's,
John