On Tue, Jun 25, 2024 at 10:24:31AM +0200, Alexander Leidinger via Postfix-users 
wrote:

> > how to deploy the following email security features?
> >      RFC 7672 SMTP-DANE
> 
> Outgoing:
> # validate DANE
> smtp_dns_support_level = dnssec
> smtp_tls_security_level = dane   # or dane-only
> (https://www.postfix.org/TLS_README.html)

But, crucially, also a local *validating* resolver is a pre-requisite,
and the libc stub resolver needs to see ad "AD" bit for validated
results, therefore, at least for glibc, run "unbound" or similar robust
DNSSEC resolver (and not systemd-resolved or dnsmasq or similar crude
efforts).

    /etc/resolv.conf:
        nameserver 127.0.0.1
        options edns0 trust-ad

> Incoming:
>  - setup DNSSEC for your domain (out of scope here on the postfix list)
>  - publish TLSA records

BEFORE publishing TLSA records:

    - Implement monitoring that will in a timely manner (1 hour or less)
      alert you to any mismatch between the published TLSA records and
      the live MTA certificate chain.

        * Make sure the monitoring alerts can reach you even when your
          TLSA records are bad!

        * Monitoring must cover multiple public key algorithms, if your
          server (advanced usage) has certificates for both RSA and
          ECDSA, ...

    - Implement a robust certificare rollover process, that will not
      forcibly deploy a new certificate chain that fails to match the
      published TLSA records.

        * Simplest, use the same key for new certificates and publish "3
          * 1 1" records.

        * For a key rollover, prepublish additional TLSA records
          matching the future key, and only a few TTLs later, deploy
          a corresponding certificate chain.

Only when you're ready to reliably operate a server that publishes a
committment to support TLS with a particular set of keys or issuer CA
keys, should you consider publishing DANE TLSA records.  When in doubt,
don't implement DANE, a half-baked implementation that quickly and/or
periodically fails is not doing anyone any favours.

Beware policy changes at public CAs such as Let's Encrypt, pinning
certificate details you don't control requires ongoing vigilance to keep
up with service change announcements, ...

    
https://list.sys4.de/hyperkitty/list/dane-us...@list.sys4.de/message/ZTM3XQMI3XP7PWMWJTXBYDPVU4UENE24/
         
-- 
    Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Reply via email to