On Mon, Jan 03, 2022 at 09:47:44AM -0800, Dan Mahoney wrote:
> Also...the server I'm sending to has a legit signed cert that matches
> its hostname, so the message I get is:
>
> Trusted TLS connection established to prime.gushi.org[149.20.68.142]:25:
> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
This means that some WebPKI trust-anchor from your CAfile or CApath is
the ultimate issuer of the ovserved server certificate. No name checks
were requested or performed (the security level is "may" or "encrypt")
and the connection is not "Verified".
> Whereas if pure DANE had been used, I think the wording there would be
> "Verified", not Trusted.
Yes, when "usable" TLSA records are published, DANE is either
"Verified", or else the connection is aborted.
> I'm guessing if there's a full cert path, that "wins"? Is TLSA still
> validated at all in this case?
That guess is not correct. Postfix honours the specified security
level. If you request "dane" you get DANE. You then only get "Trusted"
when TLSA records are not published, or DNSSEC validation is not
reported by the stub resolver (AD bit is not seen by Postfix).
> The TLSA record verification (or even the lookup) never gets logged,
> at least at loglevel 2. This would be useful for admins to see how
> much traction DANE is getting. Is there a logging knob that will
> enable this?
For TLSA record lookups to happen you need:
smtp_dns_support_level = dnssec
# Either globally, or for the nexthop domain via the TLS policy table
smtp_tls_security_level = dane
And the A/AAAA records of the MX host need to be in a DNSSSEC-signed
zone.
> And again, dropping a header into the body of the mail message so that
> the admin on the *receiving* server could see that their TLSA records
> are good for more than just getting periodic "hey your record's broke"
> emails from Viktor :)
That's not terribly effective while the largest sending sites have not
yet implemented DANE, and even then would probably not add the prposed
header.
To check whether your DANE implementation is working, *monitor* it by
making regular (at least hourly)connections that check for the presence
of TLSA records and that they match the presented certificate chain.
If you're sophisticated enough to have both RSA and ECDSA (or, bleeding
edge, ed25519) certificates, make sure to check both, by making separate
connections with the TLS cipher preferences set to enable either just
RSA or just ECDSA (ed25519, ...).
For somewhat stale (up to ~24 hours) news of your server's DANE support
see:
https://stats.dnssec-tools.org/explore/
DANE TLSA records should only be published if you:
* Have a robust cert/key rollover process that never results in
a mismatch between the live cert chain and recently advertised
(possibly still cached by a remote DNS resolver) TLSA records.
That is, updated TLSA records matching both old and new certs
are pre-published sufficiently in advance of the cert deployment.
* Have monitoring in place, and tested that notification of any
problems will get through to the responsible operators.
Otherwise, best for all concerned if you accept the (for most low) risk
of active MiTM tampering with inbound SMTP traffic.
Similar operational diligence also applies with MTA-STS (a kludge that
is best avoided).
--
Viktor.
