January 2019 - dane-users

Overview of outbound DANE for SMTP support
by Knubben, B.S.J. (Bart) - Forum Standaardisatie 26 May '21

26 May '21

Hi, We made the following overview of products/services with outbound DANE support (i.e. DANE verification). Any remarks/additions are welcome. I. Supported: - Postfix (since version 2.11.0, January 2014): http://www.postfix.org/TLS_README.html#client_tls_dane - Halon (since version 3.4-r2, November 2015): https://halon.io/dane and https://wiki.halon.io/DANE - OpenSSL (since version 1.1.0, August 2016): https://www.openssl.org/docs/manmaster/man3/SSL_CTX_dane_enable.html and https://www.openssl.org/docs/manmaster/man1/openssl-s_client.html - Cloudmark (since version 5.2, March 2017): https://blog.cloudmark.com/2017/03/27/dane-and-email-security/ - Exim (since version 4.91, April 2018): https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp… - Mail-in-a-Box (uses Postfix): https://github.com/mail-in-a-box/mailinabox/blob/master/security.md - ldns (uses OpenSSL): https://www.nlnetlabs.nl/documentation/ldns/dane_8h.html II. Requested: - Cisco: Bug ID: CSCuo87918 - [ Feature Request] TLS DANE Support for Email Security Appliance, https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuo87918/ - MS O365: https://office365.uservoice.com/forums/273493-office-365-admin/suggestions/… and https://office365.uservoice.com/forums/289138-office-365-security-complianc… - Fortinet: https://fortinet.uservoice.com/forums/23797-fortipartner-feature-requests/s… - Protonmail: https://protonmail.uservoice.com/forums/284483-feedback/suggestions/3433882… and https://protonmail.uservoice.com/forums/284483-feedback/suggestions/1659360… BTW a simple outbound DANE test can be found on https://havedane.net. -- Best regards, Bart Knubben Dutch Standardisation Forum https://www.forumstandaardisatie.nl/content/english Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

5 6

Re: Wildcard certificate and DANE/TLSA records
by Viktor Dukhovni 02 Jan '19

02 Jan '19

> On Jan 2, 2019, at 1:32 PM, zorion <zorion(a)autistici.org> wrote: > > What are the implications of not having the private key in this file? I > currently do not have it there, and I see no problems (postfix 3.1.8), > but its possible I'm not seeing something. When the key and certs are in separate files you lose the ability to atomically replace both, and introduce brief races when a Postfix process is loading the key and certs while key rotation is happening. In Postfix 3.4, when the cert and key are in the same file, the race is eliminated. The condition is temporary, and infrequent, but best avoided entirely. As for the key first, that's a longer story, but you won't go wrong doing it that way. -- Viktor.

1 0

Re: Wildcard certificate and DANE/TLSA records
by Viktor Dukhovni 02 Jan '19

02 Jan '19

On Tue, Jan 01, 2019 at 12:08:35PM -0500, zorion wrote: > > No, you just put all the requisite certificates along with the > > private key in a mode 0600, root-owned smtpd_tls_cert_file. The > > server certificate first, then its issuer CA, then any parent issuer > > CA, ... up to possibly the root CA, if that's the DANE trust-anchor > > matching the TLSA record. If the "2 1 1" TLSA record is for an > > intermediate CA, then the root CA can be left out, but still list > > any intermediates above that, for non-DANE clients. > > When I put the private key in that file, how is the file structured? The order of the certificates is subject first then issuer. The key can appear anywhere, but for compatibility with upcoming features in Postfix 3.4, put it first. 1. private key 2. corresponding end-entity certificate 3. issuer of 2 if any 4. issuer of 3 if any ... N. root-CA issued certificate (required for regular PKI) N+1. optional root-CA if published as DANE trust-anchor -- Viktor.

1 0

Update on stats 2018-12
by Viktor Dukhovni 01 Jan '19

01 Jan '19

Credits: The coverage of DNSSEC domains continues to improve with ongoing data support from Paul Vixie of Farsight Security. Credits also due to ICANN for gTLD data via CZDS, and to the TLD registries for .CH, .COM, .DK, .FR, .INFO, .IS, .LI, .NL, .NU, .ORG and .SE. More data sources of ccTLD signed delegations welcome. Summary: The DANE domain count is now 774,820 This month's adoption bump can be credited to vevida.com who enabled DANE for ~33 thousand domains. Thank you vevida.com. The number of domains with DNSSEC MX records is 8,878,369. Thus DANE TLSA is deployed on 8.72% of domains with DNSSEC. There are somewhat fewer DNSSEC domains this month. This is because a hosting provider with O(200k) previously signed domains is modernizing their DNSSEC stack (moving to ECDSA I hear), but chose to disable DNSSEC in the interim. With a bit of luck, the numbers will soon be back up, and perhaps there'll be DANE support as well. As of today I count 774,820 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 DNS/email hosting providers who've enabled DANE support for the customer domains they host. The top 20 MX host providers by domain count are: 399441 one.com 117127 transip.nl 96917 domeneshop.no 35201 active24.com 32626 vevida.com 23894 udmedia.de 10707 bhosted.nl 10587 wido.info 5654 previder.nl 3577 interconnect.nl 2521 provalue.nl 2369 nederhost.nl 1619 nmugroup.com 1456 yourdomainprovider.net 1288 hi7.de 1286 xcellerate.nl 1073 surfmailfilter.nl 1023 soverin.net 783 omc-mail.com 693 sciver.net The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.cz/.de/.eu/.be. Speaking of countries, the IPv4 GeoIP distribution of DANE-enabled MX hosts shows the below top 20 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented): 4581 TOTAL 1522 DE, Germany 964 US, United States 599 NL, Netherlands 368 FR, France 160 GB, United Kingdom 142 CZ, Czech Republic 115 CA, Canada 63 CH, Switzerland 60 SG, Singapore 58 SE, Sweden 46 BR, Brazil 40 DK, Denmark 35 IE, Ireland 35 AT, Austria 28 AU, Australia 27 FI, Finland 25 RU, Russian Federation 23 GR, Greece 22 PL, Poland 22 JP, Japan IPv6 is still comparatively rare for MX hosts, and the top 20 countries by DANE MX host IPv6 GeoIP are (same top 6). 2296 TOTAL 893 DE, Germany 428 US, United States 358 NL, Netherlands 204 FR, France 78 CZ, Czech Republic 70 GB, United Kingdom 41 SE, Sweden 33 SG, Singapore 24 CH, Switzerland 19 AT, Austria 15 IE, Ireland 12 SI, Slovenia 12 FI, Finland 12 CA, Canada 11 BR, Brazil 10 NO, Norway 9 ID, Indonesia 9 AU, Australia 8 DK, Denmark 6 RU, Russian Federation There are 3801 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 5488. These cover 5896 distinct MX hosts (some MX hosts share the same TLSA records through CNAMEs). The number of domains that at some point were listed in Gmail's email transparency report is 208 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 116 are in recent (last 90 days of) reports: gmx.at lrz.de markteffectmail.nl nic.br mail.de ouderportaal.nl registro.br posteo.de overheid.nl gmx.ch ruhr-uni-bochum.de pathe.nl open.ch tum.de photofacts.nl anubisnetworks.com uni-erlangen.de photofactsacademy.nl gmx.com unitybox.de politie.nl habr.com unitymedia.de rijksoverheid.nl hotelsinduitsland.com web.de rotterdam.nl kpn.com dk-hostmaster.dk saxion.nl mail.com egmontpublishing.dk ssonet.nl one.com netic.dk transip.nl societe.com tilburguniversity.edu truetickets.nl solvinity.com eupvsec.eu uvt.nl t-2.com insee.fr xs4all.nl trashmail.com octopuce.fr domeneshop.no xfinity.com web200.hu handelsbanken.no xfinityhomesecurity.com comcast.net webcruitermail.no xfinitymobile.com dd24.net atelkamera.nu active24.cz dns-oarc.net aegee.org atlas.cz gmx.net debian.org centrum.cz habramail.net freebsd.org cuni.cz hr-manager.net gentoo.org destroystores.cz inexio.net ietf.org itesco.cz mpssec.net isc.org klubpevnehozdravi.cz procurios.net lazarus-ide.org nic.cz r4p3.net mailbox.org smtp.cz t-2.net netbsd.org virusfree.cz transip.net openssl.org volny.cz xs4all.net samba.org allsecur.de xworks.net torproject.org bayern.de ardanta.nl asf.com.pt bund.de bhosted.nl handelsbanken.se elster.de boekwinkeltjes.nl minmyndighetspost.se fau.de boozyshop.nl personligalmanacka.se freenet.de hierinloggen.nl skatteverket.se gmx.de hr.nl t-2.si jpberlin.de hro.nl govtrack.us kabelmail.de intermax.nl Of the ~775000 domains, 2186 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 253. Some of these have additional MX hosts that don't have broken TLSA records, so mail can still arrive via the remaining MX hosts. A partial list is available at: https://github.com/danefail/list To avoid getting listed, please make sure to monitor the validity of your own 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, the number of "real" email domains with bad DNSSEC support stands at 508. The top 10 name server operators with problem domains are: 50 dotserv.com 36 tiscomhosting.nl 30 sylconia.net 30 nrdns.nl 27 metaregistrar.nl 24 active24.cz (customer zones with broken wildcard cnames) 21 nazwa.pl (customer zones with broken wildcard NS RRs) 13 movenext.nl 13 host-redirect.com 11 is.nl If anyone has good contacts at some of these providers, please encourage them to remediate not only the broken domains (I can send them a list), but also the root cause that makes the breakage possible. Four of the domains all whose nameservers have broken denial of existence appear in historical Google reports: trt1.jus.br trtrio.gov.br trtrj.jus.br trt01.gov.br -- 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