July 2016 - dane-users - list.sys4.de

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
by Viktor Dukhovni 13 Sep '16

13 Sep '16

I've gained access to the full zone files for .com/.net and a few of the newer gTLDs. This makes it possible to do a more comprehensive survey of DANE SMTP support. The overall DANE domain count is now ~29800, but of course this is not a dramatic rise in adoption, rather an increase in the breadth of the survey. 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 five are: 16650 transip.nl 6020 udmedia.de 1110 nederhost.net 663 ec-elements.com 180 core-networks.de 24623 TOTAL 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 1850 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. Of the 29800 domains, 336 have "partial" TLSA records, that cover only a subset of the MX hosts, while this protects traffic to some of the MX hosts, the domain is 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 50. The number of domains with bad DNSSEC support is 262. The top 10 DNS providers (by broken domain count) are: 41 isphuset.no 36 tse.jus.br 22 axc.nl 21 active24.cz 20 registrar-servers.com 15 forpsi.net 11 ovh.net 11 cas-com.net 11 bestregistrar.com 10 shockmedia.nl Forpsi have indicated they are working on a fix. Progress at isphuset.no (ulimately fsdata.se) is still stalled. If someone has working technical contacts at any of the others, please drop me a note. The number of domains that at some point were listed in Gmail's transparency report is 57 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these 32 are in the most recent report: gmx.at conjur.com.br registro.br gmx.ch gmx.com mail.com bund.de gmx.de jpberlin.de kabelmail.de lrz.de mail.de posteo.de ruhr-uni-bochum.de tum.de web.de octopuce.fr comcast.net dd24.net gmx.net t-2.net xs4all.net xworks.net xs4all.nl debian.org freebsd.org gentoo.org ietf.org netbsd.org openssl.org samba.org torproject.org The .br TLD still includes too large a fraction (10/50) of domains with incorrect TLSA RRs. This is a result of DNS hosting by registro.br, where TLSA records are easy to initially publish, but difficult to keep up to date. If a registrar hosts the DNS, but does not operate the SMTP server, TLSA record support may do more harm than good unless an easy to use API is made available to update the TLSA records (interactive Web UIs don't qualify). -- Viktor.

1 4

Postfix and PDNS
by Wolfgang Rosenauer 12 Jul '16

12 Jul '16

Hi, I just switched to PowerDNS Recursor on my Postfix mailserver since their latest version (4) now supports DNSSEC validation. Unfortunately now Postfix seems to be unable to verify DANE anymore. I always get only "Anonymous TLS connections" where I got "Verified" ones when using bind. Apparently and somewhat confirmed by tcpdump and the PowerDNS guys it seems that Postfix relies on the +AD flag to signal a DNSSEC validated response but doesn't request it. I can only find a set DO bit in the query's dump. I'm running Postfix 3.1.1 fwiw. Any idea? Thanks, Wolfgang

5 5