I totally love it! 11:30am GMT we saw the first DANE connection to web.de:
Verified TLS connection established to mx-ha02.web.de[212.227.17.8]:25:
TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)
It would be awesome to get some insights into this big deployment, to
show and help others to also deploy DNSSEC and DANE. Which software is
used, which steps were taken to slowly start using it, which problems
came up on the way and how were they solved. Any information about
increased traffic or load on the DNS-Servers, or failed mail transfers
because of buggy mailservers, would be very helpful during the next
days. Is DANE verification activated for outbound mail traffic?
I hope we get some insights here.
By the way: mail.de does not belong to United Internet (web.de,
mail.com, GMX, 1&1...)
Michael
Am 14.04.2016 um 20:38 schrieb Viktor Dukhovni:
The web.de domain has just published DANE TLSA records for its MX
hosts. This follows earlier "pilot" deployments with the smaller
mail.com and mail.de domains.
web.de. IN MX 100 mx-ha02.web.de. ; AD=1
_25._tcp.mx-ha02.web.de. IN TLSA 3 1 1
409c9e91a2a9f4d7881dbf0094b3839d4343a4a57d9bf559fdeb0c1f4c5b8b3e ; passed
Subject =
CN=mx-ha02.web.de,[email protected],L=Montabaur,ST=Rhineland-Palatinate,O=1&1
Mail & Media GmbH,C=DE
Issuer = CN=TeleSec ServerPass DE-2,street=Untere Industriestr.
20,L=Netphen,postalCode=57250,ST=Nordrhein Westfalen,OU=T-Systems Trust
Center,O=T-Systems International GmbH,C=DE
Inception = 2014-07-22T11:21:46Z
Expiration = 2017-07-27T23:59:59Z
web.de. IN MX 100 mx-ha03.web.de. ; AD=1
_25._tcp.mx-ha03.web.de. IN TLSA 3 1 1
33fccf0e82584b6133cf18d24ae592cc6cbc9cfcab13291a5585a2b20a30eb19 ; passed
Subject =
CN=mx-ha03.web.de,[email protected],L=Montabaur,ST=Rhineland-Palatinate,O=1&1
Mail & Media GmbH,C=DE
Issuer = CN=TeleSec ServerPass DE-2,street=Untere Industriestr.
20,L=Netphen,postalCode=57250,ST=Nordrhein Westfalen,OU=T-Systems Trust
Center,O=T-Systems International GmbH,C=DE
Inception = 2014-07-22T11:22:46Z
Expiration = 2017-07-27T23:59:59Z
This is a major milestone in DANE adoption. [ IIRC they host
mailboxes for a substantial fraction of the population of Germany. ]
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 failures 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-certificates-for-mail-servers-and-dane-part-2-of-2/
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
