Hello Viktor, all,
as I wrote in another mail:
... Email authentication requires two steps...
* DNSSEC
* trustworthy certificates (either trusted root or DANE) and validation ..
unless we want to resort to manually configuring trust (obviously entries in
/etc/hosts are less likely to be manipulated by an attacker)?
Both together avoid MitM. Just one leaves the other attack vector open.
Maybe some background (all summarization errors and judgments mine):
German data protection authorities level define kind of four compliance levels
for email encryption
0 - no encryption and thus definitely illegal
1 - encryption (not clearly specified whether certs need to be validated)
2 - DNSSEC + cert validation or manual trust establishment
3 - PGP or S/MIME - which imho is neither practical nor more secure
I want to support 2 but not block other communication (could of course set up a
second email server with a different domain but don´t really want to).
Unfortunately there is no option to trigger "verify" with DNSSEC and DANE is
even less adopted than DNSSEC.
I am in fact wondering whether I could just check the queue for cert issues, do
a DNSSEC test, and if that fails put the domain on encrypt only via some API
(sql update?)...
Thanks, Joachim
-----Ursprüngliche Nachricht-----
Von: owner-postfix-us...@postfix.org <owner-postfix-us...@postfix.org> Im
Auftrag von Viktor Dukhovni
Gesendet: Monday, 10 January 2022 12:16
An: postfix-users@postfix.org
Betreff: Re: TLS enforcement options?
> On 10 Jan 2022, at 10:07 pm, Joachim Lindenberg
> <postfix-us...@lindenberg.one> wrote:
>
> thanks for the insights. Based on my experience, the mail domain is almost
> never in the SANs of a certificate, not even with self-hosted domains like
> mine. In other words, secure is likely to cause a lot more manual
> configuration than verify.
> I´d definitely appreciate if mail.cloud9.net could update their configuration
> as then I could get rid of some exceptions, and others would not have to
> think about it when moving forward w.r.t. security.
Unless they also implement DNSSEC+DANE, there is no security advantage to an
"authenticated" connection to an insecurely obtained name.
Both "encrypt" and "verify" resist passive monitoring, and both are vulnerable
to active (MiTM) attacks. So I don't think there's much point in security
theatre around "veriable" certificates for unverified names.
--
Viktor.
