On Wed, Mar 29, 2023 at 12:24:22PM -0400, Bill Cole via Exim-users wrote:
> On 2023-03-29 at 04:46:17 UTC-0400 (Wed, 29 Mar 2023 10:46:17 +0200)
> Kirill Miazine via Exim-users <km@???> is rumored to have said:
>
> > Exactly. The former preventing passive data collection, the later --
> > active. Still, if *I* were to state a legal requirement that certain
> > domains use TLS, I'd also ask for verification either via TLS or
> > DANE, because just TLS is a very small win.
>
> You also need to understand that requiring verification as a
> prerequisite for encryption has unintended consequences. If you only
> allow encryption with verification, you will either break deliverability
> entirely for some mail OR fall back to transport in the clear, *to the
> same unverifiable host* which cannot be anything but less safe.
Sure, when doing ordinary opportunistic TLS, it is silly to fall back to
cleartext when/if authentication fails.
However, if TLS is *mandatory* as a matter of local policy (with no
cleartext fallback) to a *specific* set of destination domains, then it
may well make sense to also require authentication if expected to work
for the destinations in question. This of course doesn't scale, it is
only something one might configure for a small set of "special" peers.
Opportunistic DANE TLS is a scalable alternative, in which the remote
domain's MX hosts signal the expectation of support for authenticated
transport in a downgrade-resistant manner (via DNSSEC TLSA records).
This makes it possible to get "zero-conf" authentication, to a large set
of generic destinations (currently ~3.75 million domains), which may or
may not include the "special" peer domains one really cares about.
It is (at least in Postfix) also possible to configure some of one's
"special" peer domains for required DANE authentication, rather than
required trusted X.509 CA authentication. Also supported are local
"fingerprint" pins or per-destination trust-anchor CA certs or public
keys. Once local policy enters the fray, there's a large spectrum of
possibilies.
--
Viktor.
