On Tue, Aug 17, 2021 at 06:12:04PM +1000, raf wrote:
> If you use Debian stable, and ISC Bind, it has just
> become really really easy to implement DNSSEC for your
> domain(s).
Indeed, BIND 9.16 makes it dramatically easier to sign your DNS zone and
keep it signed reliably. It automates ZSK rollover, and simplifies KSK
rollover, including algorithm changes...
By all means please consider deploying DNSSEC for your zone. As with
any technology, don't just fire and forget, implement monitoring. One
tool I very much recommend is "ldns-verify-zone". It can check all
zone signatures, and whether any will expire too soon, ...
> Once DNSSEC is sorted, DANE should be relatively easy. :-) (unless you
> use LetsEncrypt)
There are two parts to implementing DANE, server and client.
- On the client side you just need a local (loopback) validating
resolver, your own zone need not be signed. With that in place
enabling DANE in the Postfix SMTP client is easy.
In http://www.postfix.org/TLS_README.html#client_tls_dane I
explained how to enable DANE selectively. That was some time
back. We should probably change the documentation to recommend:
main.cf:
# Make sure /etc/resolv.conf lists only looopback nameservers,
# if you list remote nameservers, their "AD" bit is easily
# spoofed via active MiTM attacks.
#
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
- On the server side, no configuration changes in Postfix are
required beyond deploying TLS (with a certificate that
consistently matches the published DANE TLSA records).
It is however critical to implement monitoring and a robust
key/cert rollover process from the get go, *before* you publish
your first TLSA RRset. Take care of those first, and only
then publish TLSA records.
See https://stats.dnssec-tools.org/ and the resources links at:
<https://stats.dnssec-tools.org/explore/?.>
> LetsEncrypt (or rather certbot) doesn't play super-well with DANE (for
> the way I want to do it - TLSA 3 1 1 records only, not TLSA 2 1 1
> records). There are several old threads on community.letsencrypt.org
> about DANE but I didn't find very clear actual instructions, but it's
> still very useful to read. The last URL above (I think) gives the best
> approach for my preference.
The key is to keep the key fixed unless and until you have TLSA records
in place for the next planned key. At that point, get Let's Encrypt to
renew your certificate with that key.
The main difficulty is that Let's Encrypt makes it easy to keep the key
fixed, or to generate a fresh random key (rather than a pre-configured
key as needed here). I need to polish and release my code that provides
the missing functionality, and delays the key rollover until after the
TLSA records have been in place for a sufficiently long time (multiple
TTLs).
Let's Encrypt does have a "--csr" option that sophisticated users can
use to implement the above, if you've already figured out how to do
that, great. Otherwise, just stick to a fixed key.
> Because I had an existing LetsEncrypt certificate via certbot, I
> wanted to keep using it, so (I think) I've told it to keep the same
> private key every time it renews (--reuse-key / reuse_key = True). But
> that's only OK if you are happy to keep the same private key forever,
> which would be bad. I don't know how to combine --reuse-key with
> annual key rollovers that are certbot-compatible. I'm not actually
> sure it's possible.
It is, but stay tuned...
> I only want to use TLSA 3 1 1 records (because 2 1 1 ones seem too
> fiddly for me),
Also fragile, because Let's Encrypt switches to a new issuer CA from
time to time, and some users don't pay attention to the announcements:
http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html
> so I think that I really need to change to creating my own private
> keys outside certbot, and using certbot's --csr option to get
> LetsEncrypt to certify them. That way, I can have multiple private
> keys in existence at the same time, and create TLSA records for each
> of them (i.e. current and next), and rollover to the next one on my
> own schedule.
Correct.
> If anyone has recent experience with certbot and TLSA 3
> 1 1 records, I'd appreciate any advice. Maybe I'll ask
> on community.letsencrypt.org.
I have code that solves the problem, but not yet ready for
release. It'll be called "danebot"...
> It's tempting to think it would be OK to use
> LetsEncrypt/certbot for the web, and handle mail
> separately, but the TLS certificate used for mail
> submission ports 465/587 should be CA-approved to keep
> (non-DANE aware) mail submission agents happy, and
> postfix uses the same certificate for all ports
> (25/465/587).
This is not the case. You can have a different certificate chain for
465/587 by making simple master.cf overrides either for those services,
or for port 25.
--
Viktor.
