From ietf-dane at dukhovni.org Sat Dec 1 09:36:17 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 1 Dec 2018 03:36:17 -0500 Subject: Update on stats 2018-11 Message-ID: <20181201083617.GH4140@straasha.imrryr.org> 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. From gturner at unzane.com Mon Dec 3 21:19:18 2018 From: gturner at unzane.com (Gerald Turner) Date: Mon, 03 Dec 2018 12:19:18 -0800 Subject: azathoth.unzane.com: DANE TLSA record misconfiguration In-Reply-To: <20181203070514.GL4128@straasha.imrryr.org> (Viktor Dukhovni's message of "Mon, 3 Dec 2018 02:05:15 -0500") References: <20181203070514.GL4128@straasha.imrryr.org> Message-ID: <87o9a2fjnd.fsf@zoth-ommog.unzane.com> 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 Encrypted mail preferred! OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 962 bytes Desc: not available URL: From ietf-dane at dukhovni.org Mon Dec 3 23:58:01 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 3 Dec 2018 17:58:01 -0500 Subject: azathoth.unzane.com: DANE TLSA record misconfiguration In-Reply-To: <87o9a2fjnd.fsf@zoth-ommog.unzane.com> References: <20181203070514.GL4128@straasha.imrryr.org> <87o9a2fjnd.fsf@zoth-ommog.unzane.com> Message-ID: <20181203225801.GP79754@straasha.imrryr.org> On Mon, Dec 03, 2018 at 12:19:18PM -0800, Gerald Turner wrote: > > ; 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. You're welcome. > 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. Yes, the same "3 1 2" record has been in place since at least "Thu Oct 19 23:12:23 EDT 2017", when I cut over from SQLite3 to Postgres. > 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. The survey engine encountered a new leat certificate on "Sat Dec 1 21:38:02 EST 2018", that no longer matched the TLSA record. > 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. In such configurations, you MUST publish separate TLSA records for each algorithm. Even if your server consistently prefers one algorithm over the other, some clients might support only RSA or only ECDSA. And if (as you *really* SHOULD) you follow the advice from the ICANN slides, and publish TLSA records to match both the "current" and "next" key, then you again need to do that twice: _25._tcp.mx.example.com. IN TLSA 3 1 1 _25._tcp.mx.example.com. IN TLSA 3 1 1 _25._tcp.mx.example.com. IN TLSA 3 1 1 _25._tcp.mx.example.com. IN TLSA 3 1 1 (or perhaps three times..., if you also support ed25519). > 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. Good. But I think you have too many TLSA records now: unzane.com. IN MX 10 azathoth.unzane.com. ; AD=1 NoError azathoth.unzane.com. IN A 184.105.220.20 ; AD=1 NoError azathoth.unzane.com. IN AAAA 2001:470:e861:2::2 ; AD=1 NoError _25._tcp.azathoth.unzane.com. IN CNAME azathoth-ta-ee-dual._tlsa.unzane.com. ; AD=1 NoError So far so good, but, why four "2 1 1" records? Pick either the intermediate or the root, no need to cover them all. azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 1 27d7a8ff7fdff07c3329a09690dda74cd65b58103f67564fe0f837b6f50aa485 ; AD=1 NoError azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 1 3f7380de4d9612e3fa4a143cb27d7d426ae669a4f2f36c72a8b22a190d353f95 ; AD=1 NoError azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 1 7510f3f1e79d6c1ed06e695b050ceedc6e5a8c24609228bc09b2ec86c743f939 ; AD=1 NoError azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 1 99ef1b3ce5f5755e815759959488f8dd59c7cc17326484a83f37526817aa78f8 ; AD=1 NoError And use only "2 1 1" or "2 1 2", whichever you prefer, but "2 1 1" is more than secure enough, and makes for smaller DNS packets, so drop all the "2 1 2" records. azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 2 51df1093ea3e1a2302f05cee6d6f4df574a4ff60efeefcf440a84d941beb157f7e520d3854b09ee7c1f07e27280d7163c6db8b1bd547a704e9e93bc0513fe03b ; AD=1 NoError azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 2 651268a16b36fc4e721287b8a627ab802c2d7bae982e00ccf8e5e5677a32dd947381729663d6b606fadb8f9c89d62f33d574a7a42c9413e5f137c33e5583fab4 ; AD=1 NoError azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 2 6ea9483eece1b61ac70efa6e66f64543e928000ddf264c5f6ce0d0ec1be0948840461255f178b8bed6f915b0579550961dd8739f4ec380c628f164172f7cbb86 ; AD=1 NoError azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 2 f4275dc6cadb1faf52c4397110de636aaa04e0b85762ff7f2740b0583dcb14976f93e8f55a4a795068608673c8f5469aae007ed20c11856ce4cd597828cbc5a8 ; AD=1 NoError And finally we see two 3 1 1 records, presumably one for RSA and another for ECDSA. Again drop the "3 1 2", but if you really feel more vigour in your step by publishing "3 1 2", then drop "3 1 1". No need to publish both. azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 3 1 1 69588ebf0bf87d04fe24ff9f6b0104ee35a0d788cccb0ac90361492aa6711a27 ; AD=1 NoError azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 3 1 1 ab1050b29bfa92cb69a2d3c4d9836cf984120131a0d48783deb9fee4031ec43c ; AD=1 NoError azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 3 1 2 77cebe0d37187c0ad490de5f97b329ea6488e20f8a166d6fea3949a1555fbc8dd6f39d6f16bdf2858f2bc0de22c11de709232c6e687e3e45bd814ea8e4ad46eb ; AD=1 NoError azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 3 1 2 ee8dad1abbb174615af798cf240f044ee176e4a761bd156e2adc2aa496b7a315af1c5b04ff8ba3fe48a4457f87bded23c5d76a3c8743040b9d69ff302046f768 ; AD=1 NoError The chain matches both "X 1 1" and "X 1 2" at every depth, but has a rather odd "Organization" value (shouwn in hex U+ABCD notation): azathoth.unzane.com[184.105.220.20]: pass: TLSA match: depth = 0, name = azathoth.unzane.com TLS = TLS12 with ECDHE-ECDSA-AES256GCM-SHA384 name = azathoth.unzane.com name = mail.unzane.com depth = 0 Issuer CommonName = Unzane Intermediate Certificate Authority (ECDSA) Issuer Organization = U+1F184 U+1F17D U+1F189 U+1F170 U+1F17D U+1F174 notBefore = 2014-04-07T17:27:00Z notAfter = 2038-01-19T03:14:07Z Subject CommonName = azathoth.unzane.com pkey sha256 [matched] <- 3 1 1 ab1050b29bfa92cb69a2d3c4d9836cf984120131a0d48783deb9fee4031ec43c pkey sha512 [matched] <- 3 1 2 77cebe0d37187c0ad490de5f97b329ea6488e20f8a166d6fea3949a1555fbc8dd6f39d6f16bdf2858f2bc0de22c11de709232c6e687e3e45bd814ea8e4ad46eb depth = 1 Issuer CommonName = Unzane Certificate Authority (ECDSA) Issuer Organization = ... notBefore = 2014-04-07T17:27:00Z notAfter = 2038-01-19T03:14:07Z Subject CommonName = Unzane Intermediate Certificate Authority (ECDSA) Subject Organization = ... pkey sha256 [matched] <- 2 1 1 99ef1b3ce5f5755e815759959488f8dd59c7cc17326484a83f37526817aa78f8 pkey sha512 [matched] <- 2 1 2 51df1093ea3e1a2302f05cee6d6f4df574a4ff60efeefcf440a84d941beb157f7e520d3854b09ee7c1f07e27280d7163c6db8b1bd547a704e9e93bc0513fe03b depth = 2 Issuer CommonName = Unzane Certificate Authority (ECDSA) Issuer Organization = ... notBefore = 2014-04-07T17:27:00Z notAfter = 2038-01-19T03:14:07Z Subject CommonName = Unzane Certificate Authority (ECDSA) Subject Organization = ... pkey sha256 [matched] <- 2 1 1 3f7380de4d9612e3fa4a143cb27d7d426ae669a4f2f36c72a8b22a190d353f95 pkey sha512 [matched] <- 2 1 2 651268a16b36fc4e721287b8a627ab802c2d7bae982e00ccf8e5e5677a32dd947381729663d6b606fadb8f9c89d62f33d574a7a42c9413e5f137c33e5583fab4 > 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 because of the green > highlighted row "3, 1, 2 ee8dad1abbb17461[...]9d69ff302046f768" was the > RSA record that had existed prior to the fixes. Yes, "dane.sys4.de" prefers RSA, while my survey scan engine prefers ECDSA. Good to have more than one perspective. -- Viktor. From groualland at proofpoint.com Thu Dec 6 16:42:44 2018 From: groualland at proofpoint.com (Gael Roualland) Date: Thu, 6 Dec 2018 16:42:44 +0100 Subject: DANE SMTP behavior with inconsistent initial CNAME response Message-ID: <455146c8-d5aa-d919-6275-f33f7d9922f8@proofpoint.com> 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. From ietf-dane at dukhovni.org Thu Dec 6 17:14:56 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 6 Dec 2018 11:14:56 -0500 Subject: DANE SMTP behavior with inconsistent initial CNAME response In-Reply-To: <455146c8-d5aa-d919-6275-f33f7d9922f8@proofpoint.com> References: <455146c8-d5aa-d919-6275-f33f7d9922f8@proofpoint.com> Message-ID: <20181206161455.GZ79754@straasha.imrryr.org> On Thu, Dec 06, 2018 at 04:42:44PM +0100, Gael Roualland wrote: > - 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. A careful DANE implementation will generally not employ DANE for unsigned domains. > 1) MX lookup for the domain: returns "1 mail.domain.tld." (from zone A) This is unsigned, and so you could stop DANE processing at that point. However, some DANE implementations (e.g. recent Postfix versions) still employ DANE even for domains with "insecure" MX records, when the selected MX host is in a signed zone. > 2) A/AAAA lookup for "mail.domain.tld": returns "A 192.168.1.1" through > "CNAME domain.tld." (from zone B) Yes, that can happen, what a mess. The destination domain's DNS is broken, and DANE or not, it is lucky to get any mail at all. > 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) So long as the NODATA answer is "insecure", the fact that it denies the CNAME's existence is tolerable, the sole purpose of the CNAME lookup is probe for DNSSEC in the original zone, and an "insecure" NODATA shows the zone to be unsigned. > 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. I would suggest that it is OK to be less "suspicious". While zone content can vary between nameservers, the DNSSEC status of a domain should be robust. > 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. You should be fine. > 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 ? Your instinct is reasonable. It is OK to continue with this domain. By the way, it is news to me that Proofpoint supports DANE. Congratulations and welcome to the club! Do you support both DANE-EE(3) and DANE-TA(2)? The most recent opensource Sendmail snapshot I can find still has fairly minimal DANE support. Is there somewhere a public description of DANE support in Proofpoint? -- Viktor. From groualland at proofpoint.com Thu Dec 6 18:37:09 2018 From: groualland at proofpoint.com (Gael Roualland) Date: Thu, 6 Dec 2018 18:37:09 +0100 Subject: DANE SMTP behavior with inconsistent initial CNAME response In-Reply-To: <20181206161455.GZ79754@straasha.imrryr.org> References: <455146c8-d5aa-d919-6275-f33f7d9922f8@proofpoint.com> <20181206161455.GZ79754@straasha.imrryr.org> Message-ID: On 6/12/18 17:16, Viktor Dukhovni wrote: >> 1) MX lookup for the domain: returns "1 mail.domain.tld." (from zone A) > > This is unsigned, and so you could stop DANE processing at that > point. However, some DANE implementations (e.g. recent Postfix > versions) still employ DANE even for domains with "insecure" MX > records, when the selected MX host is in a signed zone. This is what we offer as an option too (default on) and which is enabled in that case. However we could still have a similar behavior if the original domain is signed, but the MX hostname is in a non-signed zone or an alias to a non-signed name. >> 2) A/AAAA lookup for "mail.domain.tld": returns "A 192.168.1.1" through >> "CNAME domain.tld." (from zone B) > > Yes, that can happen, what a mess. The destination domain's DNS > is broken, and DANE or not, it is lucky to get any mail at all. Indeed... >> 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) > > So long as the NODATA answer is "insecure", the fact that it denies > the CNAME's existence is tolerable, the sole purpose of the CNAME > lookup is probe for DNSSEC in the original zone, and an "insecure" > NODATA shows the zone to be unsigned. Agreed, we could look only at the validation result here. But assuming we get the same inconsistency in a secure way, then would that also be enough to apply DANE using the initial name as the TLSA domain ? >> 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. > > I would suggest that it is OK to be less "suspicious". While zone > content can vary between nameservers, the DNSSEC status of a domain > should be robust. OK. > Your instinct is reasonable. It is OK to continue with this domain. > > By the way, it is news to me that Proofpoint supports DANE. > Congratulations and welcome to the club! Do you support both > DANE-EE(3) and DANE-TA(2)? The most recent opensource Sendmail > snapshot I can find still has fairly minimal DANE support. Is there > somewhere a public description of DANE support in Proofpoint? Thanks. I'm referring to the Cloudmark Security Platform product. Cloudmark was acquired by Proofpoint a year ago. I can't speak for DANE support status in other Proofpoint products. We do support DANE-EE and DANE-TA, and try to adhere to the specification as much as possible. We have a blog post about it at [1] but that doesn't go into technical implementation details. Ga?l. [1] https://blog.cloudmark.com/2017/03/27/dane-and-email-security/ From ietf-dane at dukhovni.org Thu Dec 6 18:55:55 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 6 Dec 2018 12:55:55 -0500 Subject: DANE SMTP behavior with inconsistent initial CNAME response In-Reply-To: References: <455146c8-d5aa-d919-6275-f33f7d9922f8@proofpoint.com> <20181206161455.GZ79754@straasha.imrryr.org> Message-ID: <1306C3C6-932F-4D01-A48E-A064EE86B150@dukhovni.org> > On Dec 6, 2018, at 12:37 PM, Gael Roualland wrote: > > Agreed, we could look only at the validation result here. > But assuming we get the same inconsistency in a secure way, then would that also be enough to apply DANE using the initial name as the TLSA domain ? If the originally observed CNAME's fully expanded target is insecure, or there are no TLSA records with that name as the base domain, then you can indeed proceed to probe for TLSA records at the original name. If the full CNAME expansion result is secure, then necessarily the origin is also secure, so you don't even need to make the "initial CNAME" query. mx.original.example. IN CNAME mx.step1.example. ; AD=(0|1) ... mx.step.example. IN CNAME mx.step.example. ; AD=(0|1) mx.step.example. IN A 192.2.0.1 ; AD=(0|1) [ Typically the resolver delivers the whole chain with a single AD bit value, so it is either "1" for all, or 0 for the whole response, but then you don't know where in the chain it stopped being secure. ] a. "mx.step.example" is secure (all the AD bits are 1), and associated secure TLSA RRset found. * use "mx.step.example" as TLSA base domain with corresponding TLSA records b. expanded CNAME is secure (all AD bits are 1), and no secure TLSA associated with the expanded name. * check for secure TLSA at original name c. expanded CNAME is insecure (one of the AD bits is 0). Check security status of initial name via an "mx.original.example. IN CNAME ?" query. You only need the validation status (AD bit) not the result. * If "insecure", done no DANE. * If "secure", look for TLSA RRset with "mx.original.example" as TLSA base domain. * If lookup failure (timeout, servfail whether DNSSEC-related or not), try a different MX host or defer. -- Viktor. From groualland at proofpoint.com Fri Dec 7 11:39:45 2018 From: groualland at proofpoint.com (Gael Roualland) Date: Fri, 7 Dec 2018 11:39:45 +0100 Subject: DANE SMTP behavior with inconsistent initial CNAME response In-Reply-To: <1306C3C6-932F-4D01-A48E-A064EE86B150@dukhovni.org> References: <455146c8-d5aa-d919-6275-f33f7d9922f8@proofpoint.com> <20181206161455.GZ79754@straasha.imrryr.org> <1306C3C6-932F-4D01-A48E-A064EE86B150@dukhovni.org> Message-ID: <636c999e-3aef-74c8-1674-84749f885a08@proofpoint.com> On 6/12/18 18:57, Viktor Dukhovni wrote: > a. "mx.step.example" is secure (all the AD bits are 1), and > associated secure TLSA RRset found. > > * use "mx.step.example" as TLSA base domain with corresponding > TLSA records > > b. expanded CNAME is secure (all AD bits are 1), and no secure TLSA > associated with the expanded name. > > * check for secure TLSA at original name Yes, this is what we currently do. > c. expanded CNAME is insecure (one of the AD bits is 0). Check security > status of initial name via an "mx.original.example. IN CNAME ?" > query. You only need the validation status (AD bit) not the result. > > * If "insecure", done no DANE. > * If "secure", look for TLSA RRset with "mx.original.example" > as TLSA base domain. > * If lookup failure (timeout, servfail whether DNSSEC-related or not), > try a different MX host or defer. That's what I was referring to. So this confirms that validation is enough whether "secure" or "insecure". We'll thus relax our implementation not to enforce a valid CNAME reply but just check validation status on lookup success. Thanks, Ga?l. From johnpc at xs4all.net Mon Dec 10 12:42:25 2018 From: johnpc at xs4all.net (Jan-Pieter Cornet) Date: Mon, 10 Dec 2018 12:42:25 +0100 Subject: DANE SMTP behavior with inconsistent initial CNAME response In-Reply-To: <1306C3C6-932F-4D01-A48E-A064EE86B150@dukhovni.org> References: <455146c8-d5aa-d919-6275-f33f7d9922f8@proofpoint.com> <20181206161455.GZ79754@straasha.imrryr.org> <1306C3C6-932F-4D01-A48E-A064EE86B150@dukhovni.org> Message-ID: Um, putting an alias (record with CNAME) in an MX record is still frowned upon by the RFCs (specifically, 2181 and 5321). So do you really want to promote a standard that goes against that, and that can result in very brittle setups? 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. So in your terminology: a. mx.step.example is secure (all the AD bits are 1): * use the original domain as the base for TLSA lookups b. some lookups are insecure: check security status of original domain via "mx.original.example CNAME ?" query. * if secure, again use "mx.original.example" as base domain for TLSA lookups * if not secure, no DANE. * on failure (servfail, timeout): - if any previous query for this delivery was DNSSEC signed (AD=1), tempfail delivery to this MX record (take next record if any) - if no DNSSEC found, no DANE, try to deliver as usual (remote DNS server might fail on CNAME queries). 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. In your original proposal: On 6-12-18 18:55, Viktor Dukhovni wrote: > a. "mx.step.example" is secure (all the AD bits are 1), and > associated secure TLSA RRset found. > > * use "mx.step.example" as TLSA base domain with corresponding > TLSA records ... 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. If any, I'd put it in the standard saying: if all other TLSA record lookups failed, implementation MAY check mx.step.example" as base domain for TLSA lookup. > b. expanded CNAME is secure (all AD bits are 1), and no secure TLSA > associated with the expanded name. > > * check for secure TLSA at original name As explained above, I'd recommend to make this the default. The way it's specified here, it may cause a brittle setup that can break easily. Imagine an organisation that had their DANE TLSA setup right, at one point. Now someone changes the mx.original.example into a CNAME to mx.stepN.example. Practically all mail delivery these days allows that CNAME, and mail delivery will follow. Assume the TLSA records are copied to the mx.stepN.example. Now the keys are rolled, and the _25._tcp.mx.stepN.example records are updated (assuming automatic rollover). The original TLSA records are forgotten. Nobody checks them anyway. Then, due to some fluke, DNSSEC fails for stepN.example (maybe the domain is moved?), and suddenly the TLSA records at the original domain get checked again by DANE. Those still contain the (hashes of the) old keys, and mail delivery breaks. Nothing changed at "original.example" to where the mail is addressed, but DNSSEC status at "stepN.example" changed. That's a very hard to debug situation. > c. expanded CNAME is insecure (one of the AD bits is 0). Check security > status of initial name via an "mx.original.example. IN CNAME ?" > query. You only need the validation status (AD bit) not the result. > > * If "insecure", done no DANE. > * If "secure", look for TLSA RRset with "mx.original.example" > as TLSA base domain. > * If lookup failure (timeout, servfail whether DNSSEC-related or not), > try a different MX host or defer. ... except, as metioned above, that CNAME query is new in the email delivery landscape, so I'd opt on the side of caution (ignore any error) if you haven't seen any DNSSEC signed domain at this point. -- Jan-Pieter Cornet "Any sufficiently advanced incompetence is indistinguishable from malice." - Grey's Law -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: OpenPGP digital signature URL: From ietf-dane at dukhovni.org Mon Dec 10 14:27:45 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 10 Dec 2018 08:27:45 -0500 Subject: DANE SMTP behavior with inconsistent initial CNAME response In-Reply-To: <26d47153-b43c-bcfb-31b5-2cbabf1c67bd@xs4all.nl> References: <455146c8-d5aa-d919-6275-f33f7d9922f8@proofpoint.com> <20181206161455.GZ79754@straasha.imrryr.org> <1306C3C6-932F-4D01-A48E-A064EE86B150@dukhovni.org> <26d47153-b43c-bcfb-31b5-2cbabf1c67bd@xs4all.nl> Message-ID: <20181210132745.GF79754@straasha.imrryr.org> 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.example.com. ; Actual TLSA record data for the real MX host. ; _25._tcp.mx.step.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.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. From johnpc at xs4all.net Mon Dec 10 15:41:17 2018 From: johnpc at xs4all.net (Jan-Pieter Cornet) Date: Mon, 10 Dec 2018 15:41:17 +0100 Subject: DANE SMTP behavior with inconsistent initial CNAME response In-Reply-To: <20181210132745.GF79754@straasha.imrryr.org> References: <455146c8-d5aa-d919-6275-f33f7d9922f8@proofpoint.com> <20181206161455.GZ79754@straasha.imrryr.org> <1306C3C6-932F-4D01-A48E-A064EE86B150@dukhovni.org> <26d47153-b43c-bcfb-31b5-2cbabf1c67bd@xs4all.nl> <20181210132745.GF79754@straasha.imrryr.org> Message-ID: On 10-12-18 14:27, Viktor Dukhovni 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. I really meant 2181 (Clarification to DNS specification), which is still current, but... > The specification is carefully considered, and deals with the world > as it is, not how I might like it to be. Fair enough, I realize MX-pointing-to-CNAME exists and we have to live with it. It would be a good idea for DANE SMTP verifiers to verify both ends of the CNAME (chain) for any TLSA records, and whether they match the real record. Just to avoid any pitfalls as I described. > 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. It still breaks mail delivery if you get it wrong though. Opportunistic DANE also means blocking the connection if there are TLSA records but they don't match. > [on only checking original MX host TLSA records] > Often, when CNAMEs are used, not present, so domain remains insecure. That's indeed the biggest disadvantage of my proposal. > 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. I'm not suggesting to skip the CNAME query. I'm suggesting to not treat errors from that query as blocking for delivery, if there is no DNSSEC signed domain involved. Since the CNAME query is a new addition to the mail delivery landscape, you risk running into unexpected results from nameservers. ... for which you give an excellent example yourself :) > 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 As *.mail.protection.outlook.com is unsigned, there is no reason to lookup TLSA records, so the ServFail for the TLSA lookup shouldn't harm anyone. I didn't suggest any changes to that part of the protocol. (In fact, I don't think any DANE implementation even does the TLSA lookup on a non-signed result from the A query of the mx host?)\ Oh, PS: nist-gov.mail.protection.outlook.com. IN CNAME ? ; ServFail AD=0 (The nameserver actually returns NOTIMP, which is converted to ServFail by the local resolver). Now in this case the CNAME query isn't needed since there is no CNAME record involved, but still, it shows that nameservers can fail the CNAME query. -- Jan-Pieter Cornet Systeembeheer XS4ALL Internet bv www.xs4all.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: OpenPGP digital signature URL: From ietf-dane at dukhovni.org Mon Dec 10 15:55:24 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 10 Dec 2018 09:55:24 -0500 Subject: DANE SMTP behavior with inconsistent initial CNAME response In-Reply-To: References: <455146c8-d5aa-d919-6275-f33f7d9922f8@proofpoint.com> <20181206161455.GZ79754@straasha.imrryr.org> <1306C3C6-932F-4D01-A48E-A064EE86B150@dukhovni.org> <26d47153-b43c-bcfb-31b5-2cbabf1c67bd@xs4all.nl> <20181210132745.GF79754@straasha.imrryr.org> Message-ID: <6D394F50-9FCA-4227-8BBC-BDF7C2C2DB5D@dukhovni.org> > On Dec 10, 2018, at 9:41 AM, Jan-Pieter Cornet wrote: > > I'm not suggesting to skip the CNAME query. I'm suggesting to not treat errors from that query as blocking for delivery, if there is no DNSSEC signed domain involved. Since the CNAME query is a new addition to the mail delivery landscape, you risk running into unexpected results from nameservers. You should stop. The CNAME record can't be a problem, it is only made, *after* discovering that the A/AAAA records for the MX host, involve a CNAME, and the response AD bit is 0: Q: mx.example.com. IN A ? R: mx.example.com. IN CNAME mx.example.net. ; AD=0 mx.example.net. IN A 192.0.2.1 ; AD=0 Only then does one make a CNAME query: Q: mx.example.com IN CNAME ? R: mx.example.com IN CNAME mx.example.net. ; AD=??? to discover the whether the original zone is signed, > ... for which you give an excellent example yourself :) My example shows why and how we *avoid* making the problematic TLSA query, by making sure we know the security status of the MX host's zone. The text in the specification is not some hastily constructed ad hoc choice. Please consider the possibility that there are good reasons for the choices made. I am done with this topic for now. -- Viktor. From zorion at autistici.org Mon Dec 31 18:52:38 2018 From: zorion at autistici.org (zorion) Date: Mon, 31 Dec 2018 12:52:38 -0500 Subject: Wildcard certificate and DANE/TLSA records Message-ID: 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. From ietf-dane at dukhovni.org Mon Dec 31 19:51:33 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 31 Dec 2018 13:51:33 -0500 Subject: Wildcard certificate and DANE/TLSA records In-Reply-To: References: Message-ID: <20181231185133.GR79754@straasha.imrryr.org> On Mon, Dec 31, 2018 at 12:52:38PM -0500, zorion wrote: > I'm working with a wildcard certificate[0] for a domain that I'm trying > to add dane/tlsa records. [side comment] I don't recommend these. They often lead to single-point of failure problems, as the certificate tends to be replaced at the same time across all MX hosts, and if there's a problem they all fail. If you have just one MX host, you don't need a wildcard certificate, if you have many, you gain a single point of failure. Better to have a separate certificate for each MX host. [/side comment] > [...] 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. No. That's not the problem. > 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 You're using the *end-entity* certificate to compute a digest that you then advertise as a digest of the *trust-anchor* issing CA. Naturally, these fail to match. Here's what "danecheck" has to report (the "-->>" arrows are added by me): riseup.net. IN MX 10 mx1.riseup.net. ; AD=1 NoError mx1.riseup.net. IN A 198.252.153.129 ; AD=1 NoError mx1.riseup.net. IN AAAA ? ; AD=1 NODATA _25._tcp.mx1.riseup.net. IN CNAME tlsa._mxdane.riseup.net. ; AD=1 NoError tlsa._mxdane.riseup.net. IN TLSA 2 0 1 3814e3eaf91e30451790697a98b1b5594cdbdfef4a73ef5a47ed33c556816645 ; AD=1 NoError mx1.riseup.net[198.252.153.129]: tlsa-mismatch TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384 name = *.riseup.net name = riseup.net depth = 0 Issuer CommonName = COMODO RSA Domain Validation Secure Server CA Issuer Organization = COMODO CA Limited notBefore = 2018-10-15T00:00:00Z notAfter = 2019-10-15T23:59:59Z Subject CommonName = *.riseup.net 1-->> cert sha256 [nomatch] <- 3 0 1 3814e3eaf91e30451790697a98b1b5594cdbdfef4a73ef5a47ed33c556816645 pkey sha256 [nomatch] <- 3 1 1 ff62cc1ec0a038b0eeebc323924be6caed3b3d56edcc9bfb943c1f2d09cdfb77 depth = 1 Issuer CommonName = COMODO RSA Certification Authority Issuer Organization = COMODO CA Limited notBefore = 2014-02-12T00:00:00Z notAfter = 2029-02-11T23:59:59Z Subject CommonName = COMODO RSA Domain Validation Secure Server CA Subject Organization = COMODO CA Limited 2-->> cert sha256 [nomatch] <- 2 0 1 02ab57e4e67a0cb48dd2ff34830e8ac40f4476fb08ca6be3f5cd846f646840f0 pkey sha256 [nomatch] <- 2 1 1 9253b6de74f67a11435c27f1dde1d30d1112333ddab23d66b8efb86887638ae6 depth = 2 Issuer CommonName = AddTrust External CA Root Issuer Organization = AddTrust AB notBefore = 2000-05-30T10:48:38Z notAfter = 2020-05-30T10:48:38Z Subject CommonName = COMODO RSA Certification Authority Subject Organization = COMODO CA Limited 3-->> cert sha256 [nomatch] <- 2 0 1 4f32d5dc00f715250abcc486511e37f501a899deb3bf7ea8adbbd3aef1c412da pkey sha256 [nomatch] <- 2 1 1 82b5f84daf47a59c7ab521e4982aefa40a53406a3aec26039efa6b2e0e7244c1 depth = 3 Issuer CommonName = AddTrust External CA Root Issuer Organization = AddTrust AB notBefore = 2000-05-30T10:48:38Z notAfter = 2020-05-30T10:48:38Z Subject CommonName = AddTrust External CA Root Subject Organization = AddTrust AB 4-->> cert sha256 [nomatch] <- 2 0 1 687fa451382278fff0c8b11f8d43d576671c6eb2bceab413fb83d965d06d2ff2 pkey sha256 [nomatch] <- 2 1 1 942a6916a6e4ae527711c5450247a2a74fb8e156a8254ca66e739a11493bb445 In potential match 1 the digest matches, but the usage is "3 0 1", and your TLSA record is "2 0 1", so no go. In 2, 3 and 4, the digests don't match. > ..., or generate the hash over the wrong > pieces? Yes. > 0. yes, I am aware of why wildcards are discouraged, but this is what I > have to work with here. Yes, with care they can be made to work. -- Viktor. From ietf-dane at dukhovni.org Mon Dec 31 20:21:50 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 31 Dec 2018 14:21:50 -0500 Subject: Wildcard certificate and DANE/TLSA records In-Reply-To: References: <20181231185133.GR79754@straasha.imrryr.org> Message-ID: > On Dec 31, 2018, at 2:01 PM, zorion 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: chaingen Type: application/octet-stream Size: 1876 bytes Desc: not available URL: -------------- next part -------------- More resources at: https://github.com/baknu/DANE-for-SMTP/wiki/1.-Implementation-resources -- Viktor. From zorion at autistici.org Mon Dec 31 23:33:16 2018 From: zorion at autistici.org (zorion) Date: Mon, 31 Dec 2018 17:33:16 -0500 Subject: Wildcard certificate and DANE/TLSA records In-Reply-To: References: <20181231185133.GR79754@straasha.imrryr.org> Message-ID: On 12/31/18 2:21 PM, Viktor Dukhovni wrote: >> On Dec 31, 2018, at 2:01 PM, zorion 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: