> On Nov 6, 2019, at 10:17 AM, Bastian Blank
> <[email protected]> wrote:
>
>> Now, I know that what is good for web servers/browsers, isn't
>> necessarily the same for SMTP servers. For example, I've learned from
>> this mailing list that public facing MTAs should not require
>> super-strong ciphers because that may force another MTA to use
>> unencrypted communication:
>
> You can do that if you at the same time _enforce_ encryption, for
> example on submission.
A floor of TLS 1.2 for mandatory inbound TLS (essentially just
submission) is not unreasonable:
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
And yet it is perhaps still too early to disable TLSv1 for opportunistic
TLS. Even among security-conscious SMTP servers that have DANE TLSA
records (solicit mandatory inbound encryption), some still only support
TLSv1. In the DANE survey dataset counting frequencies of protocol version
by unique SMTP server name offering at most that protocol I see:
IPv4:
32 TLS10
3086 TLS12
3095 TLS13
IPv6:
14 TLSv1
1559 TLSv1.2
1713 TLSv1.3
So around 0.5% of DANE-enabled SMTP servers support only TLSv1. I'd
hazard a guess that the rate is higher among SMTP servers in general.
Sadly, this means that even:
# Not yet!
# smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
is likely premature. And even though nobody seems to have a need for
TLSv1.1, definitely avoid:
# Bad idea. OpenSSL does not handle "protocol holes" in the way
# you'd expect, you end up enabling only the protocols below the
# first "hole"!
#
# DO NOT DO THIS! It amounts to enabling only "TLSv1".
#
# smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1.1
--
Viktor.
