On Tue, Nov 03, 2015 at 04:05:33PM +0000, Ian Eiloart wrote:
> > Generating a self signed certificate at install time could be fraught
> > with problems: what if there is an insecure OpenSSL/LibreSSL/whatever
> > library installed and used?
>
> Rather than use a self-signed certificate, why not use LetsEncrypt.org to
> get a free domain bound certificate with widespread trust anchors?
>
> https://letsencrypt.org/getinvolved/
On port 25 CA-issued certificates are pointless. Opportunistic
TLS does not check them. They are only useful for port 587 (and
465) submission.
https://tools.ietf.org/html/rfc7672#section-1.3
Self-signed certificates work better on port 25. Their "expiration"
need not creating regular pre-scheduled outages. Just make them
last 100 years, and do key rotation when you're good and ready,
not when some certificate is pre-programmed to "expire".
With DANE-EE(3) TLSA records, they verify just fine, and expiration
is based on the TLSA record, not the certificate content.
> They�ve expressed an interest in getting an Exim plugin to assist with
> creation and deployment of certificates. The plugins help prove domain
> ownership and then install the certificate.
"Prove domain ownership" is a rather strong claim. Nothing of the
sort is actually "proved". Rather, an insecure channel is used to
create trust ex nihilo.
When you trust an LE certificate, you're trusting that the same
MITM attacker (possibly none) that tricked LE is still there on
your connection to the destination domain.
So, the use-case for LE is primarily the MSA use-case, and that
may be worth supporting, and this may even require SNI with multiple
certs if you're the MSA for multiple logical SMTP server names.
I would expect that supporting LE certs for MSAs is a separate
question from whether to enable opportunistic TLS on port 25 by
default.
One possible model to encourage deployment is to ship a command-line
interface that does all the work in one step, and then leave it to
distributions and/or users to turn it on. Distribution maintainers
who have not already done so, might then integrate turning on TLS
into their packages (possibly with prompts, ...).
If you do implement integration with LE, be careful to not
automatically break DANE. If users publish DANE-EE(3) TLSA RRs,
but an LE plugin automatically rotates keys/certs without updating
TLSA records, it can cause outages.
https://tools.ietf.org/html/rfc7671#section-8.1
https://tools.ietf.org/html/rfc7671#section-8.4
For LE, the TLSA record would have to be DANE-TA(2) with the LE
root as the issuer, and that root would have to be part of the
configured wire chain. See:
https://tools.ietf.org/html/rfc7671#section-5.2
and subsections.
--
Viktor.
