November 2016 - dane-users

Best practice TLSA RRs for CA-issued certs
by Viktor Dukhovni 30 Dec '16

30 Dec '16

[ This assumes you are willing to trust your issuer CA to not misissue certificates for your domain, and include the CA certificate in your server chain file. ] One approach to making sure that DANE TLSA records are less likely to fail that should work well for sites using CA-issued certificates is to publish both "3 1 1" and "2 1 1" TLSA records: mx.example. IN TLSA 3 1 1 <digest of server public key> mx.example. IN TLSA 2 1 1 <digest of immediate issuer public key> * The "3 1 1" record protects against "expiration" accidents, and unexpected changes in the issuer's public key (if new certificate chain deployment is automated). * The "2 1 1" record protects against key rotation errors should a a new server private key be deployed without updating the TLSA RRs. Provided the new certificate is issued by the same CA is unexpired, ... the "2 1 1" record will match. With a bit of monitoring to ensure that both records match, simultaneous failure of both is much less likely. This even makes it possible to avoid pre-deployment DNS TLSA records updates when rotating certificates, provided at least one of the issuer public key or the server public key is unchanged in the new chain. In particular, this is the best practice with Let's Encrypt issued SMTP server certificates, as explained in: https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certifi… -- Viktor.

3 13

Update on stats (no major changes)
by Viktor Dukhovni 28 Nov '16

28 Nov '16

As of today I count 103599 domains with correct DANE TLSA records for SMTP. As expected the bulk of the DANE domains are hosted the handful of DNS/hosting providers who've enabled DANE support in bulk for the domains they host. The top 10 MX host providers by domain count are (bit.nl is a newcomer to the top 10 list): 42124 domeneshop.no 32486 transip.nl 15100 udmedia.de 1759 bhosted.nl 1266 nederhost.net 903 ec-elements.com 374 core-networks.de 305 uvt.nl 258 bit.nl 207 omc-mail.com The real numbers are surely larger, because I don't have access to the full zone data for any ccTLDs, and in particular .de and .nl. There are 2191 unique zones in which the underlying MX hosts are found, this counts each of the above registrars as just one zone, so is a measure of the breadth of adoption in terms of servers deployed. Alternatively, a similar number is seen in the count (2297) of distinct MX host server certificates that support the same ~104000 domains. Of the ~104000 domains, 772 have "partial" TLSA records, that cover only a subset of the MX hosts. While this protects traffic to some of the MX hosts, such domains are still vulnerable to the usual active attacks via the remaining MX hosts. The number of domains with incorrect TLSA records or failure to advertise STARTTLS (even though TLSA records are published) stands at 61 (~10 are recent additions that will likely be resolved soon, the remaining ~50 are the long-term stable population of broken domains). The number of domains with bad DNSSEC support is 388. The top 10 DNS providers (by broken domain count) are: 49 axc.nl 39 infracom.nl 25 binero.se 23 registrar-servers.com 20 loopia.se 19 active24.cz 16 forpsi.net 12 cas-com.net 11 jsr-it.nl 10 ignum.com Around 100 of the broken domains have at least one working nameserver, and so are email-reachable, given enough retries. The number of domains that at some point were listed in Gmail's transparency report is 91 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these 44 are in the most recent report: gmx.at jpberlin.de t-2.net conjur.com.br lrz.de xs4all.net registro.br mail.de overheid.nl gmx.ch posteo.de xs4all.nl open.ch ruhr-uni-bochum.de domeneshop.no anubisnetworks.com tum.de webcruitermail.no gmx.com uni-erlangen.de debian.org mail.com unitybox.de freebsd.org trashmail.com unitymedia.de gentoo.org xfinity.com web.de ietf.org bayern.de octopuce.fr netbsd.org bund.de comcast.net openssl.org fau.de dd24.net samba.org gmx.de gmx.net torproject.org ish.de hr-manager.net -- Viktor.

1 0

Letsencrypt-dane-tlsa-bind9
by John ＠ KLaM 21 Nov '16

21 Nov '16

Ice recently had to switch CA, I was using Startcom but recent events make them unaccuptable. I have decided to go with Letsencrypt. This works for most things but is giving me some headaches with DANE/TLSA. I can generate the tlsa for my dns ( bind 9) using Victor's tlsagen script. I direct the output into a file which I will be included in the DNS zone file using ($include). I am not going the CSR route so I am assuming that if I do this whenever certbot is run I should wind up with an upto date tlsa record. My problem is how to get bind to recognise that there has been change. Is this a workable idea? What have I got wrong? TIA John A

3 2

posttls-finver vs. dane.sys4.de
by Andreas Schulze 02 Nov '16

02 Nov '16

Hello, we found messages to "sushi-circle.de" stay in our MTA facing outside world: "status=deferred (TLSA lookup error for login.enterprise-email.com:25)" dane.sys4.de doesn't mention any problems. in contrast: # posttls-finger sushi-circle.de posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.login.enterprise-email.com type=TLSA: Host not found, try again posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.login.enterprise-email.com type=TLSA: Host not found, try again posttls-finger: Failed to establish session to sushi-circle.de via login.enterprise-email.com: TLSA lookup error for login.enterprise-email.com:25 I guess some piece of software is wrong... force $destdomain to encrypt only let postfix deliver the messages. Andreas

2 1