On Fri, Apr 17, 2020 at 03:59:49PM -0700, PGNet Dev wrote:
> Real World DANE Inter-domain email transport
>
> https://static.ptbl.co/static/attachments/169319/1520904692.pdf
More at:
https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
Specific issues:
https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md
https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17
https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html
> Any favorites/recommendations for current "what/why" & "how to" DNSSEC/DANE
> with Postfix docs/tutorials/posts/etc?
Postfix documentation covers the client side, but the DANE for servers
HOTWO has not yet been written. This is partly because there's little
that's Postfix-specific there. What's required is general operational
discipline around monitoring, DNSSEC and certificate management taking
cached TLSA records into account.
> Particularly for completely-new-to-DNSSEC/DANE, but mostly
> self-sufficient with Postfix otherwise, admins?
The client side is easy:
* Postfix >= 2.11, but at this point 3.2 is the oldest still supported.
* Loopback validating resolver, e.g. BIND or unbound.
* Only 127.0.0.1 in /etc/resolv.conf
* smtp_dns_support_level = dnssec
* smtp_tls_security_level = dane
The server side is where the operational discipline is needed:
* To manage and monitor DNS (tools improving, BIND 9.16 highly
recommended with much better support for automatic signing and
ZSK, and KSK rollover).
- Monitor slave replication
- Monitor signature expiration
- Monitor consistency of glue NS records with zone apex
- Monitor DS RRset vs. KSK consistency
* To manage and monitor TLSA records:
- pre-publish new TLSA RRs multiple TTLs before making
the corresponding certificate chain changes.
- make sure that TLSA RRs cover every support SNI name,
and as appropriate the cert chain for each algorithm
(RSA, ECDSA, ...) for which you have certificates.
- monitor the correctness of the TLSA records by running
frequent (say hourly) tests of all applicable certificate
chains (SNI and/or algorithm-specific).
- monitor STARTTLS support to make sure that STARTTLS is
consistently available, certificates are not expired (when
publishing "2 1 1", or similar DANE-TA(2) records), that
all expected TLS protocol versions work (TLSv1.2 required,
TLSv1.3 recommended).
- ...
Writing all of this down in detail is a non-trivial project, and would
perhaps be a small book. I've not had the cycles... :-(
I've started work on some text for this to add to the Postfix
TLS_README, but it won't cover all the topics, and will only sketch out
the requirements, the reader will need to fill in various details from
other sources (or prior experience).
--
Viktor.
