On Tue, Aug 17, 2021 at 12:35:40PM -0400, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> 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, ... So far, I've just setup trivial monitoring (cron+sh+host) that emails me whenever bind adds or removes KSK DNSKEY/CDS/CDNSKEY records from the zones. That should give me enough notice to know when I need to add/remove DS records via the registrar. But well thought out monitoring would be better. Thanks. > > 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. A note about debian-11. libc no longer assumes that the AD flag in DNS responses can be trusted. If it can be (i.e. if the only name server is 127.0.0.1 and if it verifies), then you should add "options trust-ad" to /etc/resolv.conf (or to whatever software creates /etc/resolv.conf). > 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 Yes. I wondered why those settings weren't the default recommendation rather than "may", but postfix doesn't know anything about your resolver. It would be good to document/recommend doing whatever it takes outside postfix to be able to have those settings. But the above comment should also mention the requirement that the loopback nameserver must do dnssec validation. It might still not be the default everywhere(?). > - 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/?.> Thanks. > > 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. I'm not a certbot expert, but from what I've been reading, it seems that --csr and renew are mutually exclusive. There are recommendations to keep the key the same with certbot renew --reuse-key, but to occasionally rollover the key with --csr. But I don't understand how that is supposed to work. I'd like to see a tutorial with all the actual commands needed. I'm currently effectively doing renew with reuse key until I work out what to do for key rollovers, but I think what it has to be is that I create a new separate key with --csr and and switch over to it and just cron certbot --csr instead of certbot renew. The problem is that I don't see how you can have multiple certificates for the same domain at the same time with certbot, because of its /etc/letsencrypt directory layout. I'll need to experiment with an unimportant domain that I can risk breaking. :-) Maybe I need to investigate acme.sh or some other LetsEncrypt client. I'm hoping the tutorial in the last URL I included will do what I want. It looks very promising. I need to read it again carefully and try it out. It would be great if certbot supported multiple simultaneous certificates for a domain, so that the next certificate could be ready in advance. Then pre/post/deploy hooks could take care of everything fairly easily. But I might have to wait for debian-12 or debian-13 for that. :-) > > 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... Sounds good. > > 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"... I like it already. :-) > > 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. Of course! Brilliant. I should have thought of that. I guess the most pragmatic thing to do would be to only use DANE/TLSA for port 25 with self-signed certificates with self-automated rollovers, and use certbot-created certificates (without corresponding TLSA records) for everything else. But I'd like to eventually be able to publish TLSA records for all the ports (25/443/465/587/993/995). But that's hardly urgent. It can wait for danebot. Let me know when it's ready for testing. > -- > Viktor. cheers, raf
