December 2018 - 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 zorion 01 Jan '19

01 Jan '19

On 12/31/18 2:21 PM, Viktor Dukhovni wrote: >> On Dec 31, 2018, at 2:01 PM, zorion <zorion(a)autistici.org> wrote: >> >> Ok, I had a hard time finding out what exactly the *trust-anchor* was >> supposed to be. I took a guess that it was the combined cert chain, but >> obviously that is not it. > A trust-anchor is any issuing CA you designate as trusted, and it does > not have to be a root CA, it can also be any intermediate CA. Thank you for the explanation! >> What exactly is the trust-anchor? Is it the top level cert from the CA >> in the chain (#4 in your danecheck below)? > It is any of 2, 3 or 4. The important constraint with DANE-TA(2), as > explained in https://tools.ietf.org/html/rfc7671#section-5.2.2, is > that if you do choose a root CA as your trust-anchor, unlike the > case in non-DANE PKIX protocols, it MUST be sent to the client along > with the intermediate issuer certificates. Would that be the smtp_tls_CAfile option in postfix? I've got an intermediate bundle that I provide to that option in main.cf > To compute the digest of a CA certificate, create a PEM file containing > just that certificate. Or use my "chaingen" script (attached), which > can process a complete chain of certificates, but DO NOT then publish > all the TLSA records it outputs. Publish no more than one TLSA record > per certificate in the chain, typically just the "3 1 1" for the EE > cert, and "2 1 1" for the TA certs. And no need to match at every > level. At most two trust anchors (typically just one) are enough. Thanks! Is there a benefit for also publishing the "2 1 1" TA certs if I'm already publishing the "3 1 1" EE cert? ps. accidentally only sent this directly to Viktor, sending it to the list.

2 1

Re: Wildcard certificate and DANE/TLSA records
by Viktor Dukhovni 31 Dec '18

31 Dec '18

> On Dec 31, 2018, at 2:01 PM, zorion <zorion(a)autistici.org> wrote: > > Ok, I had a hard time finding out what exactly the *trust-anchor* was > supposed to be. I took a guess that it was the combined cert chain, but > obviously that is not it. A trust-anchor is any issuing CA you designate as trusted, and it does not have to be a root CA, it can also be any intermediate CA. > What exactly is the trust-anchor? Is it the top level cert from the CA > in the chain (#4 in your danecheck below)? It is any of 2, 3 or 4. The important constraint with DANE-TA(2), as explained in https://tools.ietf.org/html/rfc7671#section-5.2.2, is that if you do choose a root CA as your trust-anchor, unlike the case in non-DANE PKIX protocols, it MUST be sent to the client along with the intermediate issuer certificates. To compute the digest of a CA certificate, create a PEM file containing just that certificate. Or use my "chaingen" script (attached), which can process a complete chain of certificates, but DO NOT then publish all the TLSA records it outputs. Publish no more than one TLSA record per certificate in the chain, typically just the "3 1 1" for the EE cert, and "2 1 1" for the TA certs. And no need to match at every level. At most two trust anchors (typically just one) are enough. More resources at: https://github.com/baknu/DANE-for-SMTP/wiki/1.-Implementation-resources -- Viktor.

1 0

Wildcard certificate and DANE/TLSA records
by zorion 31 Dec '18

31 Dec '18

Hello, I'm working with a wildcard certificate[0] for a domain that I'm trying to add dane/tlsa records. There are a series of MX servers that use this certificate and I thought that I could put the specific name of the server into the TLSA record and that would work, but when I try to test that with one of the testers online, they fail to verify it, I think because there is no specific match to the name. For example, I made these records using the certificate chain for the input to danetool: danetool --tlsa-rr --host mx1.riseup.net --load-certificate ./wildcard_server_chain.pem --app-proto=smtp --ca --x509 _25._tcp.mx1.riseup.net. IN CNAME tlsa._mxdane.riseup.net. tlsa._mxdane.riseup.net. IN TLSA ( 02 00 01 3814e3eaf91e30451790697a98b1b5594cdbdfef4a73ef5a47ed33c556816645 ) But when I try to test that, I get: ################################################################# ### CHECKING MX HOST: mx1.riseup.net ################################################################# TLSA records found: 1 TLSA: 2 0 1 3814e3eaf91e30451790697a98b1b5594cdbdfef4a73ef5a47ed33c556816645 Connecting to IPv4 address: 198.252.153.129 port 25 recv: 220-mx1.riseup.net ESMTP (spam is not appreciated) recv: 220 mx1.riseup.net ESMTP (spam is not appreciated) send: EHLO cheetara.huque.com recv: 250-mx1.riseup.net recv: 250-PIPELINING recv: 250-SIZE 25600000 recv: 250-ETRN recv: 250-STARTTLS recv: 250-ENHANCEDSTATUSCODES recv: 250-8BITMIME recv: 250 DSN send: STARTTLS recv: 220 2.0.0 Ready to start TLS TLSv1.2 handshake succeeded. Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 Peer Certificate chain: 0 Subject CN: *.riseup.net Issuer CN: COMODO RSA Domain Validation Secure Server CA 1 Subject CN: COMODO RSA Domain Validation Secure Server CA Issuer CN: COMODO RSA Certification Authority 2 Subject CN: COMODO RSA Certification Authority Issuer CN: AddTrust External CA Root 3 Subject CN: AddTrust External CA Root Issuer CN: AddTrust External CA Root SAN dNSName: *.riseup.net SAN dNSName: riseup.net Error: peer authentication failed. rc=65 (No matching DANE TLSA records) [2] Authentication failed for all (1) peers. I suspect this is because the SAN dNSName does not specify mx1.riseup.net? I cannot find any specific details for how wildcards are handled in the RFCs. Did I define the record incorrectly, or generate the hash over the wrong pieces? I thought maybe it was because I used the PEM encoded cert chain, but its not possible to generate a DER when the input is a multiple cert file. Thanks for any help! 0. yes, I am aware of why wildcards are discouraged, but this is what I have to work with here.

2 1

Re: DANE SMTP behavior with inconsistent initial CNAME response
by Viktor Dukhovni 10 Dec '18

10 Dec '18

On Mon, Dec 10, 2018 at 12:41:00PM +0100, Jan-Pieter Cornet wrote: > Um, putting an alias (record with CNAME) in an MX record is still frowned > upon by the RFCs (specifically, 2181 and 5321). Yes, but they are used in practice, and I don't know of any MTAs that refuse to follow the CNAMEs, so one has to live with their de facto use, despite the fact that they're undefined in RFC 5321 and legacy 2821, 821. > So do you really want to promote a standard that goes against that, and > that can result in very brittle setups? There are two sides to this issue: * What the receiving domain should do, to configure interoperable security. * What the sending MTA should do, to deliver securely when possible. On the *receiving* side: 1. Avoid CNAMEs if at all possible, use already canonical hostnames in MX records. 2. If you do use a CNAME, and want to enable DANE, publish TLSA records on *both* sides of the CNAME chain: ; TLSA record alias under original MX hostname to TLSA RRset ; under fully-expanded MX hostname: ; _25._tcp.mx.example.com. IN CNAME _25._tcp.mx.step<N>.example.com. ; Actual TLSA record data for the real MX host. ; _25._tcp.mx.step<N>.example.com. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 However, on the sending side, we check both places, with the fully-expanded target preferred. Because: 1. Customers who publish MX CNAMEs to the MX host of their provider, generally don't know or neglect to also publish CNAMEs for the associated TLSA records. 2. Some customers attempt to publish TLSA data (not just an alias to the real TLSA RRset at the provider) on their end of the CNAME chain, but they don't manage key rollover for the target host, and inevitably have out-of-sync TLSA records. If the provider publishes "real" TLSA records, checking there first works better. Yes, when CNAMEs are using on the receiving side, the setup can be fragile when configured sloppily, some receiver configurations are less secure than others. This is *opportunistic* DANE TLS. > I would propose to make this check a lot simpeler: always take the domain > found in the MX record as the base domain for corresponding TLSA lookups. > And only do the TLSA lookups if the domain name of that MX record is DNSSEC > protected. That way, if a CNAME is introduced, it doesn't change the > TLSA-protected status of the original domain, or break things in case > DNSSEC is suddenly added or dropped from a remote zone. There's no "break things". If TLSA records are published on the remote end, they're surely more authoritative for the actual certificate chain of the underlying host. If they're not published, then the fallback behaviour is exactly as you describe. > So in your terminology: > > a. mx.step<N>.example is secure (all the AD bits are 1): > * use the original domain as the base for TLSA lookups Often, when CNAMEs are used, not present, so domain remains insecure. > The upshot of all this is that nothing should change for those that aren't > doing DNSSEC or TLSA records. You're already introducing a possible CNAME > query that isn't used in the current mail delivery mechanism, and there's > no telling what that would cause in the real world. It has happened in the > past that DNS servers return SERVFAIL on any CNAME query due to bugs. The CNAME query is needed, only and exactly when the A records are found on the far side of a CNAME chain. This is the case even for your proposal, because that's what it takes to determine whether the MX host lies in a secure zone, and skip TLSA records if not. If one attempts TLSA lookups in unsigned zones one can't deliver any mail to any of the hundreds of thousands of signed domains hosted by Microsoft at outlook.com: nist.gov. IN MX 0 nist-gov.mail.protection.outlook.com. ; NoError AD=1 nist-gov.mail.protection.outlook.com. IN A 23.103.198.42 ; NoError AD=0 _25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA ? ; ServFail AD=0 > ... you're effectively approving the "MX points to CNAME" case. Which happens, > but is not considered best practice, so I wouldn't recommend to make this > case the first preference. The specification is carefully considered, and deals with the world as it is, not how I might like it to be. -- Viktor.

2 2

DANE SMTP behavior with inconsistent initial CNAME response
by Gael Roualland 10 Dec '18

10 Dec '18

Hello DANE users, One of our customers brought to our attention failure to deliver email to some domains with a very broken DNS setup when enabling Opportunistic DANE. The impacted domains have different name servers at the zone and TLD delegation level, and these name servers serve different zone content for the domain, eg for say a "domain.tld": - some of these serve a valid zone content such as (A): domain.tld. IN MX 1 mail.domain.tld. mail.domain.tld IN A 192.168.1.1 - others server a "parking" like zone (B): *.domain.tld. IN CNAME domain.tld. domain.tld. IN A 192.168.1.2 None of these zones are signed. When trying to check for DANE support for the domain, the following scenario can happen if data from both zones is intermixed: 1) MX lookup for the domain: returns "1 mail.domain.tld." (from zone A) 2) A/AAAA lookup for "mail.domain.tld": returns "A 192.168.1.1" through "CNAME domain.tld." (from zone B) 3) Since the A reply is insecure and is from a CNAME alias, as per §2.2.2 of the RFC we issue an explicit CNAME request on "mail.domain.tld." to check if this is secure: this returns a NODATA answer (from zone A) In that case, our implementation considers that having a NODATA answer to a CNAME that it received previously in a former response is suspicious, and temporary fails this delivery attempt as if we hit a DNS error. (Subsequent retries may have a different reply order subject to DNS caches refresh, but since only the address in zone A is a valid next-hop, odds for a successful delivery are low) AFAIK, this particular case is not covered by the RFC, and we're trying to assess if degrading to Opportunistic TLS in that case instead of temporary failing could actually introduce some security flaw in the process. It seems to me that for an attacker to be able to purposely return such inconsistent answers, he would need to be able to spoof answers if zones are not signed (like here) or have either control of the zone DNS key or of the MTA's resolver, both which would allow other ways to skip DANE. I'd like to get your opinions on this. Does that sound safe ? What do other implementations do in that particular case ? Thanks, Gaël.

3 5

Re: azathoth.unzane.com: DANE TLSA record misconfiguration
by Gerald Turner 03 Dec '18

03 Dec '18

Hello Viktor, [CC'ing dane-users list to mea culpa to the Internet at large, appreciate any advice ;-)] On Mon, Dec 03 2018, Viktor Dukhovni wrote: > Your TLSA RRset does not match the actual certificate chain of some > of your MX hosts. It is better to have no TLSA records than to > have incorrect TLSA records. Please adopt a *better* key rotation > approach, what you're doing now is fragile and DOES NOT work reliably. > > Suggested more robust TLSA record management approaches are described > in slides presented at the ICANN61 conference in March of 2018: > > http://imrryr.org/~viktor/ICANN61-viktor.pdf > http://imrryr.org/~viktor/icann61-viktor.mp3 > > The relevant DNS records are: > > ; DANE TLSA fail > ; None of the TLSA records match the certificate chain > ; > _25._tcp.azathoth.unzane.com. IN CNAME azathoth-rsa._tlsa.unzane.com. > azathoth-rsa._tlsa.unzane.com. IN TLSA 3 1 2 ee8dad1abbb174615af798cf240f044ee176e4a761bd156e2adc2aa496b7a315af1c5b04ff8ba3fe48a4457f87bded23c5d76a3c8743040b9d69ff302046f768 > > Affected domains: > > unzane.com. IN MX 10 azathoth.unzane.com. Thank you for informing me of this misconfiguration at my site. I'm curious whether your DANE validation scans had found my mail server to validate successfully in the past, prior to Saturday December 1st, 8:20AM PST. Coincidentally this is time that the OpenSSL package within Debian stable/security-updates archive had been upgraded on this server, from version 1.1.0f-3+deb9u2 to version 1.1.0j-1~deb9u1. This upgrade triggered SMTP STARTTLS monitoring alarms (using Monit, checking fingerprints), which I had rectified, however I had neglected the impact to DANE. For whatever forgotten reason, the x509 certificates for this site are "dual stacked", one set of certificates for RSA, and another set of certificates for ECDSA. Postfix had been configured to support both chains of certificates (smtp_tls_cert_file + smtp_tls_eccert_file). To my surprise, the minor OpenSSL version bump must have changed cipher suite order and caused the ECDSA flavor to be served. I read your ICANN61 slides (very nice, BTW), and tried the Bash/OpenSSL DANE check function at the end. Appending openssl s_client option "-cipher 'HIGH:-ECDHE'" causes the check to pass. Nevertheless, I've updated our TLSA records to include the ECDSA flavor. Check now passes with or without the explicit cipher suites hack. Although I missed the opportunity to run your DANE/SMTP web validator¹ prior to updating my TLSA records, FWICT it looks like the web validator is using RSA flavor connections, thus would have passed prior to fixing the TLSA records for ECDSA flavor. Guessing here becuase of the green highlighted row "3, 1, 2 ee8dad1abbb17461[...]9d69ff302046f768" was the RSA record that had existed prior to the fixes. ¹ https://dane.sys4.de/smtp/unzane.com -- Gerald Turner <gturner(a)unzane.com> Encrypted mail preferred! OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D

2 1

Update on stats 2018-11
by Viktor Dukhovni 01 Dec '18

01 Dec '18

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 740,856 The substantial increase is primarily a result of newly enabled DNSSEC and DANE TLSA records for the MX hosts operated by one.com. Congratulations and thanks to one.com, and to iis.se for providing some of the incentive to make this happen. The number of domains with DNSSEC MX records is 9,035,030 Thus DANE TLSA is deployed on 8.19% of domains with DNSSEC. As of today I count 740,856 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: 400996 one.com 117219 transip.nl 97040 domeneshop.no 35065 active24.com 23768 udmedia.de 10923 bhosted.nl 10592 wido.info 5689 previder.nl 3593 interconnect.nl 2525 provalue.nl 2437 nederhost.nl 1477 yourdomainprovider.net 1290 xcellerate.nl 1249 hi7.de 1077 surfmailfilter.nl 1013 soverin.net 777 omc-mail.com 689 sciver.net 646 mailbox.org 646 core-networks.de 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 12 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented): 4463 TOTAL 1506 DE, Germany 940 US, United States 569 NL, Netherlands 359 FR, France 159 GB, United Kingdom 136 CZ, Czech Republic 111 CA, Canada 60 CH, Switzerland 58 SE, Sweden 55 SG, Singapore 49 BR, Brazil 40 DK, Denmark IPv6 is still comparatively rare for MX hosts, and the top 12 countries by DANE MX host IPv6 GeoIP are (same top 6). 2229 TOTAL 877 DE, Germany 429 US, United States 328 NL, Netherlands 199 FR, France 73 CZ, Czech Republic 68 GB, United Kingdom 36 SE, Sweden 29 SG, Singapore 23 CH, Switzerland 19 AT, Austria 15 IE, Ireland 14 FI, Finland There are 3701 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 5375. These cover 5759 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 190 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 106 are in recent (last 90 days of) reports: gmx.at mail.de markteffectmail.nl nic.br posteo.de ouderportaal.nl registro.br ruhr-uni-bochum.de overheid.nl gmx.ch tum.de pathe.nl open.ch uni-erlangen.de politie.nl anubisnetworks.com unitybox.de rotterdam.nl gmx.com unitymedia.de saxion.nl habr.com web.de transip.nl kpn.com egmontpublishing.dk truetickets.nl mail.com netic.dk uvt.nl one.com tilburguniversity.edu xs4all.nl societe.com eupvsec.eu domeneshop.no solvinity.com octopuce.fr handelsbanken.no t-2.com web200.hu webcruitermail.no trashmail.com comcast.net atelkamera.nu xfinity.com dd24.net aegee.org xfinityhomesecurity.com dns-oarc.net debian.org xfinitymobile.com gmx.net freebsd.org active24.cz habramail.net gentoo.org cuni.cz hr-manager.net ietf.org destroystores.cz inexio.net isc.org itesco.cz mpssec.net lazarus-ide.org klubpevnehozdravi.cz procurios.net mailbox.org nic.cz r4p3.net netbsd.org optimail.cz t-2.net openssl.org smtp.cz transip.net samba.org allsecur.de xs4all.net torproject.org bayern.de xworks.net asf.com.pt bund.de ardanta.nl handelsbanken.se elster.de bhosted.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 interconnect.nl lrz.de intermax.nl Of the ~740000 domains, 1911 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 246. 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 509. The top 10 name server operators with problem domains are: 50 dotserv.com 38 tiscomhosting.nl 32 sylconia.net 30 nrdns.nl 28 metaregistrar.nl 24 active24.cz (customer zones with broken wildcard cnames) 21 nazwa.pl (customer zones with broken wildcard NS RRs) 18 host-redirect.com 13 movenext.nl 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. Three of the domains all whose nameservers have broken denial of existence appear in historical Google reports: trtrj.jus.br trt01.gov.br trtrio.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