On Dec 26, 2019, at 7:29 PM, Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
I'd support a carefully-worded recommendation to use TLS when relaying, as
long as it didn't (yet) recommend blocking mail based on absence of TLS and
(probably) cautioned against doing so outside of some narrow corner cases.
+1. As much as spend cycles promoting appropriate use of TLS, I also
caution against overzealous enforcement. For example, RFC7435.
I suspect that there are a lot of devices out there sending cleartext mail,
that probably can't be upgraded for the useful lifetime of the device. And
using TLS to send mail from a device, actually makes the device more fragile
because it implies a need to upgrade the CAs that the device trusts.
For SMTP relay that's less of an issue, because unlike SUBMIT and IMAP,
SMTP (relay) STARTTLS is by default unauthenticated.
For authentication of inter-domain relay, we have DANE and MTA-STS, which
enable authentication opportunistically, when advertised by the peer.
DANE provides always on downgrade resistance, while MTA-STS is not downgrade
resistant on first contact (or when cached policies expire due to sufficiently
infrequent traffic).
(I do also wonder how many existing SMTP servers can handle TLS with client
certificates, because that seems like that would also be a recommendation
worth considering.)
Most don't request client certs, and the client can't unilaterally include
these in the TLS handshake when not requested by the server. Even when the
server does request client certs, it is presently not a good idea to send
client certs to strangers, because failure to validate these may cause
connection abort in some stacks.
Therefore, for now client certs should be enabled only for use with peers
that are known to need them (typically to authenticate outbound relaying),
and not otherwise.
Before we could encourage use of client-certs in inter-domain relaying, we'd
need to first encourage asking for them, while treating failure to validate
them as equivalent to absence of certificates, rather than reason to abort
the TLS handshake.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp