From ietf-dane at dukhovni.org Tue Jan 1 00:55:11 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 31 Dec 2018 18:55:11 -0500 Subject: Wildcard certificate and DANE/TLSA records In-Reply-To: References: <20181231185133.GR79754@straasha.imrryr.org> Message-ID: <20181231235511.GT79754@straasha.imrryr.org> On Mon, Dec 31, 2018 at 05:33:16PM -0500, zorion wrote: > > 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 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. > 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? Yes, it can simplify rollover and make your deployment less likely to fail, provided you only make changes that affect one of the values at a time. See the slides from my various talks. That said, I recommend the "3 1 1 + 3 1 1" approach as more secure. Whatever you do, have monitoring in place and avoid key rollover processes that temporarily leave your server with TLSA records that don't match its cert chain, keeping in mind remote DNS caches. Also don't forget to bump the SOA when chaning DNS records, otherwise secondary servers may keep serving stale data. For example, the below domains only provide the right TLSA record 2/3 of the time: mtexx.email. IN MX 10 mx1.mtexx.email. niklas.pro. IN MX 10 mx1.mtexx.email. ; Correct @ns1.totaldns.de.[212.224.81.8] @ns3.totaldns.be.[93.190.68.228] _25._tcp.mx1.mtexx.email. TLSA 3 1 2 1FDBE5993E99EFAB8B7DF0EF254AF72FA512697787EEA622591000141F8B9836154D600812B306C842524F6B5B747D024A3EBA8337C71538C158AAD4BCDDDCFA ; Stale @ns2.totaldns.eu.[78.47.63.220] _25._tcp.mx1.mtexx.email. TLSA 3 1 1 21DF011460CF75244534EC7E04F7EFB2A980106C7B44EE0997FC5F86A23D7DD1 Which can result in stochastic email delays. At least the TTL is only 5 minutes, so given enough retries the mail will likely get through... -- Viktor. From ietf-dane at dukhovni.org Tue Jan 1 03:50:32 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 31 Dec 2018 21:50:32 -0500 Subject: Update on stats 2018-12 Message-ID: <20190101025031.GL4140@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 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. From ietf-dane at dukhovni.org Wed Jan 2 10:10:11 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 2 Jan 2019 04:10:11 -0500 Subject: Wildcard certificate and DANE/TLSA records In-Reply-To: <693744fb-63db-ed47-f6ba-bde60eced84e@autistici.org> References: <20181231185133.GR79754@straasha.imrryr.org> <20181231235511.GT79754@straasha.imrryr.org> <693744fb-63db-ed47-f6ba-bde60eced84e@autistici.org> Message-ID: <20190102091011.GU79754@straasha.imrryr.org> 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. From ietf-dane at dukhovni.org Wed Jan 2 22:03:57 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 2 Jan 2019 16:03:57 -0500 Subject: Wildcard certificate and DANE/TLSA records In-Reply-To: <7f92d034-a2c7-20e3-c24c-c73c0c466140@autistici.org> References: <20181231185133.GR79754@straasha.imrryr.org> <20181231235511.GT79754@straasha.imrryr.org> <693744fb-63db-ed47-f6ba-bde60eced84e@autistici.org> <20190102091011.GU79754@straasha.imrryr.org> <7f92d034-a2c7-20e3-c24c-c73c0c466140@autistici.org> Message-ID: <3DFA4366-7084-408E-A142-491420E3FA99@dukhovni.org> > On Jan 2, 2019, at 1:32 PM, zorion 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.