April 2018 - dane-users

The danefail list on Github
by Viktor Dukhovni 14 Apr '18

14 Apr '18

Now that I am able to contribute commits to the danefail list at: https://github.com/danefail/list https://raw.githubusercontent.com/danefail/list/master/dane_fail_list.dat I've pushed data for many of the domains served by MX hosts with persistent issues. You can use this list to confirm that you're not the only one with delivery issues to one of the listed domains, and perhaps create exceptions for such domains in your configuration. Also, please try to not end up on the list: https://dane.sys4.de/common_mistakes http://imrryr.org/~viktor/ICANN61-viktor.pdf http://imrryr.org/~viktor/icann61-viktor.mp3 Do implement monitoring of your own TLSA records and DNSSEC zone. Do implement a key/cert rollover process that ensures that matching TLSA records are in place for both the old and the new cert have been in place for some time (multiple TTLs and slave zone refresh times) before deploying new certificate chains. When using DANE-TA(2) TLSA records, make sure that the certificate does not expire, has a name that matches the MX hostname and the trust-anchor certificate is included in the server's chain file. -- Viktor.

1 0

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
by Viktor Dukhovni 10 Apr '18

10 Apr '18

Please read the TLS WG consensus call thread on the DNSSEC chain extension, and comment for either publish as-is or the changes I and others are advocating (which IMHO are needed for plausible utility in the web space). Thread: https://www.ietf.org/mail-archive/web/tls/current/threads.html#25929 Rationale for change: https://www.ietf.org/mail-archive/web/tls/current/msg25936.html Why proposed pinning TTL is analogous to STS and not HPKP: https://www.ietf.org/mail-archive/web/tls/current/msg25956.html -- Viktor.

1 0

Re: [dane] [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension (fwd)
by Viktor Dukhovni 05 Apr '18

05 Apr '18

> On Apr 5, 2018, at 2:43 AM, John Gilmore <gnu(a)toad.com> wrote: > > Looks from this distance like the usual obstruction, i.e. "just give > us a few more years of CA revenues, by delaying this standard further > by demanding to add stuff that could easily have been added by a > followup RFC". I am confused, the folks most closely tied to the current browser/CA revenue model are proposing moving ahead with the crippled standard as-is, and those of us who want a standard that would be usable in browsers are asking for some changes, that should not cause much delay, but are needed to make the spec viable for browser HTTPS. So you comment about a follow-up RFC and delay is perplexing. I certainly do not wish delay adoption in HTTPS I'm advocating for it, but that requires a small delay in publication to add two key missing features. * Lack of denial of existence * Lack of an extended TTL that commits the server to support the extension for the specified time (and provide either TLSA records or denial of existence of same or even DS records for the domain or some parent). Without these, the protocol suffers trivial "stripping" downgrades. A server that implements DANE and supports the extension should be able to expect that clients will not ignore its absence and continue with legacy WebPKI. For if that's the case, the extension is pointless for the vast majority of applications (including browsers) where its adoption would need to be incremental. See the TLS WG discussion for details. -- Viktor.

1 0

TLS dane-chain extension: viability in browsers and the like...
by Viktor Dukhovni 05 Apr '18

05 Apr '18

If you want to (some day) see DANE support in browsers and other existing applications where adoption would be necessarily incremental, please read and consider responding on the IETF TLS WG list to: https://www.ietf.org/mail-archive/web/tls/current/msg25937.html the parent thread is: https://www.ietf.org/mail-archive/web/tls/current/threads.html#25929 where you mind other posts that flesh out the pros/cons. And of course please take a look at the draft to make your own first-hand conclusions: https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07 -- Viktor. P.S. I posted a shorter version of this on Twitter: https://twitter.com/VDukhovni/status/981682242174046210

1 0

Update on stats 2018-03
by Viktor Dukhovni 01 Apr '18

01 Apr '18

Summary: The total domain count is now 185948. Approximately 6500 of the ~10000 new domains result from processing a new source for some additional .no and .nl domain nanes. The number DNSSEC domains in the survey stands at 5382667, thus DANE TLSA is deployed on 3.45% of domains with DNSSEC. Many DNSSEC domains use third-party MX hosts, that don't have DNSSEC, so they can't benefit from DANE until their providers secure the MX hosts. Please ask your provider to enable DNSSEC and DANE on their MX hosts. [ It would be especially significant if "redirect.ovh.net" were to implement DNSSEC+DANE. If someone personally knows the right people to gently nudge at ovh.net, please do. ] As of today I count 185948 domains with correct SMTP DANE TLSA records at every primary MX host that accepts connections[1]. As expected the bulk of the DANE domains are hosted by 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: 73807 domeneshop.no 65101 transip.nl 19168 udmedia.de 6177 bhosted.nl 1807 nederhost.nl 1228 yourdomainprovider.net 867 ec-elements.com 748 surfmailfilter.nl 542 core-networks.de 438 omc-mail.de The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.nl/.de. Speaking of countries, the IPv4 GeoIP distribution of DANE-enabled MX hosts shows the below top 10 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented): 1289 DE, Germany 830 US, United States 457 NL, Netherlands 338 FR, France 164 GB, United Kingdom 109 CZ, Czech Republic 80 CA, Canada 59 SE, Sweden 58 CH, Switzerland 50 BR, Brazil IPv6 is still comparatively rare for MX hosts, and the top 10 countries by DANE MX host IPv6 GeoIP are (same top 6). 710 DE, Germany 407 US, United States 255 NL, Netherlands 195 FR, France 102 GB, United Kingdom 58 CZ, Czech Republic 33 SE, Sweden 25 CH, Switzerland 23 SG, Singapore 14 SI, Slovenia There are 3372 unique zones in which the underlying MX hosts are found, this counts each of the above providers as just one zone, so is a measure of the breadth of adoption in terms of servers deployed. The number of published MX host TLSA RRsets found is 4544. These cover 4834 distinct MX hosts (some MX hosts share the same TLSA records through CNAMEs). [ Previous reports inadvertently included some "orphan" MX hosts in the database, that are no longer tied to any domains, these are no longer reported, so the numbers are somewhat smaller this month. Without the correction, the numbers would have been 5485 and 5795. ] The number of domains that at some point were listed in Gmail's email transparency report is 131 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 72 are in recent reports: gmx.at posteo.de pathe.nl travelbirdbelgique.be ruhr-uni-bochum.de politie.nl nic.br tum.de uvt.nl registro.br uni-erlangen.de xs4all.nl gmx.ch unitybox.de domeneshop.no open.ch unitymedia.de handelsbanken.no anubisnetworks.com web.de webcruitermail.no gmx.com dk-hostmaster.dk aegee.org isavedialogue.com egmontpublishing.dk debian.org mail.com tilburguniversity.edu freebsd.org solvinity.com insee.fr gentoo.org trashmail.com octopuce.fr ietf.org xfinity.com comcast.net isc.org xfinityhomesecurity.com dd24.net netbsd.org xfinitymobile.com dns-oarc.net openssl.org bayern.de gmx.net samba.org bund.de hr-manager.net torproject.org elster.de mpssec.net asf.com.pt fau.de t-2.net handelsbanken.se freenet.de xs4all.net minmyndighetspost.se gmx.de bhosted.nl skatteverket.se jpberlin.de boozyshop.nl t-2.si lrz.de ouderportaal.nl mail.co.uk mail.de overheid.nl govtrack.us Of the ~186000 domains, 1500 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 today at 202. Some of these also have MX hosts that don't have broken TLSA records, so mail can still arrive via the remaining MX hosts. Below is the list of underlying MX hosts that serve these domains and whose TLSA records don't match reality: Hall of Shame: 88oddil.cz mail.itconnect.ro mx1.em54.net andbraiz.com mail.itsmine.com mx1.em56.net andersonvasconcelos.com.br mail.labbrack.se mx1.email.youwerehere.info anubis.delphij.net mail.lavabit.no mx2.aquasoft.cz bounder.steelyard.nl mail.lsd.is mx2.em54.net coolmx.net-art.cz mail.mxdove.com mx2.em56.net demo.liveconfig.com mail.myzt.nl mx2.email.youwerehere.info diablo.sgt.com mail.netistan.ch mx2.mindrun.de din.mta.din.cz mail.nonoserver.info mx2.pfp.de eufront.stansoft.bg mail.olgui.net petg.cz eumembers.stansoft.bg mail.pasion.ro pinus.dafcorp.net gaia.nfx.cz mail.rapidfuse.io plesk2.acknowledge.nl gamepixel.eu mail.rostit.se pop.co.za goldcars.mta.din.cz mail.scrz44.de rootbox.me gsmapp.com.br mail.seslost.cz sat-an--net.mta.din.cz homer.jpbe.de mail.victorycity.com.hk servmail.fr intranet.nctechcenter.com mail.voorschoten.nl smtp-1.httrack.com itaskmanager.ovh mail.wassenaar.nl smtp.bl.lybre.net kou--li.mta.din.cz mail.werkorganisatieduivenvoorde.nl smtp.klam.com ma.qbitnet.com mail.wodv.nl smtp.sauron-mordor.net mail.3c7.de mail.zionbit.cz smtp1.lococensus.nl mail.abanto-zierbena.org mail.zx.com smtp2.lococensus.nl mail.all4.de mail2.subse.eu solventtruck.mta.din.cz mail.allq.cz mail2.victorycity.com.hk stmics01.smia-automotive.com mail.bacrau.ro mailb.kamadu.eu stmics02.smia-automotive.com mail.castleturing.net maxhunter.com.br tusk.sgt.com mail.davidbodnar.cz milhouse.jpbe.de vm-1.eveng.de mail.digitalwebpros.com mminetto.com.br vps.du.ie mail.diplomatic.email mx.bels.cz wantuz.shannara.ru mail.dnsmadefree.com mx.datenknoten.me webmail.headsite.se mail.efflam.net mx.itconnect.ro webmail.kassoft.eu mail.familie-sander.rocks mx.mail.klinknetz.de webmail.vivisol.nl mail.fscker.nl mx.promail.saarland wizard.itsmine.com mail.i-bible.com mx01.qusign.net www.mtg.de Please make sure to monitor the validity of your TLSA records, and implement a reliable key rotation procedure. See: https://dane.sys4.de/common_mistakes http://imrryr.org/~viktor/ICANN61-viktor.pdf http://imrryr.org/~viktor/icann61-viktor.mp3 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 After eliminating parked domains that do not accept email of any kind, the number of "real" email domains with bad DNSSEC support stands at 104. The top 10 name server operators with problem domains are: 8 psb1.org 7 tse.jus.br 7 active24.cz 6 tiscomhosting.nl 5 nazwa.pl 5 metaregistrar.nl 4 ignum.com 4 glbns.com 4 army.mil 4 1cocomo.com Only one domain all whose nameservers have broken denial of existsnce appears in historical Google reports: http://dnsviz.net/d/_25._tcp.mx1.harsh.monkeybrains.net/WsEoNQ/dnssec/ http://dnsviz.net/d/_25._tcp.mx2.harsh.monkeybrains.net/WsEiKA/dnssec/ the monkeybrains.net SOA record is likely modified *after* the zone is signed, making negative replies "bogus". -- Viktor. [1] Some domains deliberately include MX hosts that are always down, presumably as a hurdle to botnet SMTP code that gives up where real MTAs might persist. I am not a fan of this type of defence (it can also impose undue latency on legitimate email). However, provided the dead hosts still have TLSA records, (which don't need to match anything, just need to exist and be well-formed) there's no loss of security.

1 0