> On Aug 23, 2016, at 3:03 PM, Phillip Carroll <domainmanager@???> wrote:
>
> I am now convinced that exim, or possibly the 'email subsystem', as it were, should have its own dedicated certificate and key. Among the many reasons for not sharing the LE-backed Web certificate is its short duration. As pointed out on another exim thread, this short duration can create a logistical nightmare to support some email-related features.
The short duration of LE certificates can create some pitfalls with DANE
TLSA records. The solution I recommend is to decouple key rotation from
certificate renewal.
https://www.ietf.org/mail-archive/web/uta/current/msg01498.html
https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766
https://community.letsencrypt.org/t/upcoming-intermediate-changes/13106
> I also now have security concerns about sharing a private key among some amorphous group of unrelated software entitities. It seems to make more sense to dedicate certificates for different purposes. Originally, my idea was to take advantage of an automated cert-renewal process, but in light of how things actually work, I no longer see that as a priority.
As highlighted by the recent DROWN attack, there is a potential for cross-protocol attacks
where security of keys used in one context can be weakened or compromised by their use in
a different context. Thus for example, one should not use the same key with both SSLv2 and
SSLv3/TLSv1.x (though one should not really use SSLv2 at all).
Therefore, on port 25, I would more typically go with a self-signed cert or a private CA
issued cert, while on port 587 one might use an LE cert that is used with HTTP, provided
both services are configured with essentially identical protocol and cipher settings
> Exim TLS appears to work quite well with a self-signed cert, which itself has an entirely automated renewal process. Although, because of fallback to unencrypted mode, I admit I can't say for certain that it "works" in the sense of all traffic being encrypted in both directions.
TLS in email is typically opportunistic and subject to active attacks, both
STARTTLS stripping and DNS forgery. See:
https://tools.ietf.org/html/rfc7672#section-1.3
https://tools.ietf.org/html/rfc7435#section-4
--
Viktor.
