On Thu, Jul 02, 2020 at 09:21:27PM -0400, Viktor Dukhovni wrote:
> Tell your customer politely, but firmly, that you are not at liberty to
> enforce TLS 1.2 inbound, as that would downgrade the security of
> connections from clients that can only do TLS 1.0. However, since
> you do support TLS 1.2, they are more than welcome to configure
> their outbound systems to use at least TLS 1.2.
In case it helps:
http://www.postfix.org/TLS_README.html#client_tls_limits
Consequently, TLS security for mail delivery to public MX hosts is
almost entirely the client's responsibility. The server is largely a
passive enabler of TLS security, the rest is up to the client.
https://tools.ietf.org/html/rfc7435#section-1.2
When protocols only offer a choice between
authenticated-and-encrypted communication, or no protection, the
result is that most traffic is sent in cleartext. The fact that
most traffic is not encrypted makes pervasive monitoring easier by
making it cost-effective, or at least not cost-prohibitive (see
[RFC7258] for more detail).
For encryption to be used more broadly, authentication needs to be
optional. The use of encryption defends against pervasive monitoring
and other passive attacks. Even unauthenticated, encrypted
communication (defined below) is preferable to cleartext.
> Don't play green check-box bingo. Actual [security] is about
> pragmatic choices not maximising checklist scores.
There is no compelling reason to disable TLS 1.0 in inbound SMTP. Its
use is fading away, and in due course it will be a more practical
option, and some users may be able to take that step now, but nothing
bad happens if you don't. There are no know practical downgrade attacks
to TLS 1.0 for authenticated SMTP.
Unauthenticated opportunstic TLS in SMTP is of course vulnerable (as
expected) to all sorts of active attacks, hence DANE, MTA-STS, manual
secure-channel configurations, ...
--
Viktor.
