From andreas.schulze at datev.de Wed Nov 2 21:52:58 2016 From: andreas.schulze at datev.de (Andreas Schulze) Date: Wed, 2 Nov 2016 21:52:58 +0100 Subject: posttls-finver vs. dane.sys4.de Message-ID: 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 From ietf-dane at dukhovni.org Wed Nov 2 22:19:52 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 2 Nov 2016 21:19:52 +0000 Subject: posttls-finver vs. dane.sys4.de In-Reply-To: References: Message-ID: <20161102211952.GO26244@mournblade.imrryr.org> On Wed, Nov 02, 2016 at 09:52:58PM +0100, Andreas Schulze wrote: > 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)" That domain has broken DNS servers, as can be seen at: http://dnsviz.net/d/_25._tcp.login.enterprise-email.com/dnssec/ The issue is that it breaks query minimization. Queries for _tcp.login.enterprise-email.com return a "bogus" NXDOMAIN (perhaps a DJBDNS server with rather incomplete DNSSEC support or a very out of date PowerDNS), while queries for _25._tcp return TLSA records... Whether any particular client detects this or not rather depends on whether the client's resolver enables query minimization. The reason TLSA records are in play for this domain, is that while the domain's zone is not DNSSEC signed, the MX host's domain is, and so by default, its TLSA records are still used with Postfix 3.1 and later: http://www.postfix.org/postconf.5.html#smtp_tls_dane_insecure_mx_policy The dane.sys4.de code does not inspect TLSA records for domains with an insecure MX RRset. You can directly test the MX host to check. Because dane.sys4.de is not doing query minimization, everything checks out. https://dane.sys4.de/smtp/login.enterprise-email.com > I guess some piece of software is wrong... No, rather the world is complicated, and not everything uses the same set of configuration options and runs into the same interop issues. Query minimization provides some additional privacy, but it has costs in both latency and reliability (runs into more bugs). It is suitable for personal machines, but may not yet be wise for servers. FWIW, The resolver I'm using at the moment is not configured for query minimization, and so: $ posttls-finger -c -l dane sushi-circle.de posttls-finger: using DANE RR: _25._tcp.login.enterprise-email.com IN TLSA 3 0 1 DC:70:0D:9F:49:F9:D2:D0:6F:86:18:46:86:86:B3:D7:A8:DC:53:4A:CB:D5:F1:51:39:5D:4A:CF:AD:00:56:19 posttls-finger: MX RRset insecure: log verified as trusted posttls-finger: login.enterprise-email.com[95.128.200.159]:25: depth=0 matched end entity certificate sha256 digest DC:70:0D:9F:49:F9:D2:D0:6F:86:18:46:86:86:B3:D7:A8:DC:53:4A:CB:D5:F1:51:39:5D:4A:CF:AD:00:56:19 posttls-finger: login.enterprise-email.com[95.128.200.159]:25: Matched subjectAltName: login.enterprise-email.com posttls-finger: login.enterprise-email.com[95.128.200.159]:25: subjectAltName: www.login.enterprise-email.com posttls-finger: login.enterprise-email.com[95.128.200.159]:25 CommonName login.enterprise-email.com posttls-finger: login.enterprise-email.com[95.128.200.159]:25: subject_CN=login.enterprise-email.com, issuer_CN=COMODO RSA Domain Validation Secure Server CA, fingerprint=38:AC:5C:74:90:66:BA:FE:45:B1:09:31:21:96:F7:C3:55:30:E7:9C, pkey_fingerprint=A0:11:EB:11:CD:BB:E3:A1:C7:F8:B9:AA:A0:E8:02:6B:47:1A:69:28 posttls-finger: Trusted TLS connection established to login.enterprise-email.com[95.128.200.159]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) -- Viktor. From john at klam.ca Mon Nov 21 03:26:30 2016 From: john at klam.ca (John @ KLaM) Date: Mon, 21 Nov 2016 15:26:30 +1300 Subject: Letsencrypt-dane-tlsa-bind9 Message-ID: <15884b4c7f0.2789.14d9188d684ea7b6d1324cf92af46b48@klam.ca> 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 From patrickdk at patrickdk.com Mon Nov 21 03:32:03 2016 From: patrickdk at patrickdk.com (Patrick Domack) Date: Sun, 20 Nov 2016 21:32:03 -0500 Subject: Letsencrypt-dane-tlsa-bind9 In-Reply-To: <15884b4c7f0.2789.14d9188d684ea7b6d1324cf92af46b48@klam.ca> Message-ID: <20161120213203.Horde.6kXVXJa97HHV6cdN3EhB5MH@mail.patrickdk.com> Quoting "John @ KLaM" : > 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. You will have an uptodate tlsa record, the problem is, everyone else won't. They will have the old cached value without this new entry. For this purpose, I do a cold rolling, and wait 2 weeks before I use the new certificate and key. It's the same idea as rotating your zsk and ksk keys. > My problem is how to get bind to recognise that there has been change. Instead of dropping it in a file, use nsupdate. From ietf-dane at dukhovni.org Mon Nov 21 05:17:16 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 20 Nov 2016 23:17:16 -0500 Subject: Letsencrypt-dane-tlsa-bind9 In-Reply-To: <15884b4c7f0.2789.14d9188d684ea7b6d1324cf92af46b48@klam.ca> References: <15884b4c7f0.2789.14d9188d684ea7b6d1324cf92af46b48@klam.ca> Message-ID: > On Nov 20, 2016, at 9:26 PM, John @ KLaM wrote: > > I've recently had to switch CA, I was using Startcom but recent events > make them unacceptable. 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). With signed zones, BIND typically does not load zone data from a text file. Instead, in most deployments, a compiled form of the zone file is maintained, which is updated as records are periodically re-signed. If you need to make manual changes to the text zone file, you need to reload (re-compile) the text zone file and make sure that you've also incremented the SOA serial number since the last change to the text file. That would be: # rndc reload "example.com" > 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 up-to-date tlsa > record. This is possible, but very much not recommended: 1. When not keeping the public key stable, you MUST pre-publish the new TLSA record along with the old, a few TTLs *prior* to deploying the new server certificate. Otherwise, outages result when remote caches still contain the old data, but the server's certificate has changed. If the script fails to insert the new record the outages last longer than the TTL. 2. You also need to ultimately remove the stale records once the new certificate and key are deployed. The whole certbot thing happens unattended and any errors are rather in the process break email delivery. So my recommendation is to in fact do CSR thing, and handle actual key rotation interactively, when you are prepared to check all the steps. Thus I highly recommend the approach outlined in: http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 > My problem is how to get BIND to recognize that there has > been change. -- Viktor. From ietf-dane at dukhovni.org Mon Nov 28 03:45:38 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 28 Nov 2016 02:45:38 +0000 Subject: Update on stats (no major changes) Message-ID: <20161128024538.GH4973@mournblade.imrryr.org> 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.