[ This assumes you are willing to trust your issuer CA to not
misissue certificates for your domain, and include the CA
certificate in your server chain file. ]
One approach to making sure that DANE TLSA records are less likely
to fail that should work well for sites using CA-issued certificates
is to publish both "3 1 1" and "2 1 1" TLSA records:
mx.example. IN TLSA 3 1 1 <digest of server public key>
mx.example. IN TLSA 2 1 1 <digest of immediate issuer public key>
* The "3 1 1" record protects against "expiration" accidents, and
unexpected changes in the issuer's public key (if new certificate
chain deployment is automated).
* The "2 1 1" record protects against key rotation errors should a
a new server private key be deployed without updating the TLSA
RRs. Provided the new certificate is issued by the same CA
is unexpired, ... the "2 1 1" record will match.
With a bit of monitoring to ensure that both records match,
simultaneous failure of both is much less likely.
This even makes it possible to avoid pre-deployment DNS TLSA records
updates when rotating certificates, provided at least one of the
issuer public key or the server public key is unchanged in the new
chain.
In particular, this is the best practice with Let's Encrypt
issued SMTP server certificates, as explained in:
https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certifi…
--
Viktor.
Hello,
I like to publish a PKIX-TA which mean I publisch a whole certificate, the whole blob...
I found https://www.huque.com/bin/gen_tlsa but some commandline voodoo using openssl or ldns-dane would be cool.
Any suggestions?
Thanks & nice weekend
Andreas
--
A. Schulze
DATEV eG
I've gained access to the full zone files for .com/.net and a few
of the newer gTLDs. This makes it possible to do a more comprehensive
survey of DANE SMTP support.
The overall DANE domain count is now ~29800, but of course this is
not a dramatic rise in adoption, rather an increase in the breadth
of the survey. As expected the bulk of the DANE domains are hosted
the handful of DNS/hosting providers who've enabled DANE support
in bulk for the domains they host. The top five are:
16650 transip.nl
6020 udmedia.de
1110 nederhost.net
663 ec-elements.com
180 core-networks.de
24623 TOTAL
The real numbers are surely larger, because I don't have access to
the full zone data for any ccTLDs, and in particular .de and .nl.
There 1850 unique zones in which the underlying MX hosts are found,
this counts each of the above registrars as just one zone, so is
a measure of the breadth of adoption in terms of servers deployed.
Of the 29800 domains, 336 have "partial" TLSA records, that cover
only a subset of the MX hosts, while this protects traffic to some
of the MX hosts, the domain is 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
at 50.
The number of domains with bad DNSSEC support is 262. The top 10
DNS providers (by broken domain count) are:
41 isphuset.no
36 tse.jus.br
22 axc.nl
21 active24.cz
20 registrar-servers.com
15 forpsi.net
11 ovh.net
11 cas-com.net
11 bestregistrar.com
10 shockmedia.nl
Forpsi have indicated they are working on a fix. Progress at
isphuset.no (ulimately fsdata.se) is still stalled. If someone
has working technical contacts at any of the others, please drop
me a note.
The number of domains that at some point were listed in Gmail's
transparency report is 57 (this is my ad-hoc criterion for a domain
being a large-enough actively used email domain). Of these 32 are
in the most recent report:
gmx.at
conjur.com.br
registro.br
gmx.ch
gmx.commail.com
bund.de
gmx.de
jpberlin.de
kabelmail.de
lrz.de
mail.de
posteo.de
ruhr-uni-bochum.de
tum.de
web.de
octopuce.fr
comcast.netdd24.netgmx.nett-2.netxs4all.netxworks.net
xs4all.nl
debian.orgfreebsd.orggentoo.orgietf.orgnetbsd.orgopenssl.orgsamba.orgtorproject.org
The .br TLD still includes too large a fraction (10/50) of domains
with incorrect TLSA RRs. This is a result of DNS hosting by
registro.br, where TLSA records are easy to initially publish, but
difficult to keep up to date.
If a registrar hosts the DNS, but does not operate the SMTP server,
TLSA record support may do more harm than good unless an easy to
use API is made available to update the TLSA records (interactive
Web UIs don't qualify).
--
Viktor.
