You are here: Home > Publications > RIPE Labs > Mihnea-Costin Grigore > Implementing DANE for RIPE NCC Websites

Implementing DANE for RIPE NCC Websites

Mihnea-Costin Grigore — 19 Nov 2015
Contributors: ivo dijkhuis
In September of this year, we activated DNS-based Authentication of Named Entities (DANE) for our main web services, including www.ripe.net, the LIR Portal, RIPE Atlas and RIPE Labs.

 

Because the RIPE NCC already used DNSSEC to sign the .ripe.net zone, this was an easy extra step to take to augment the security of our websites. Our main concerns in deploying DANE were with software support and potential incompatibility, as well as the added complexity and maintenance burden on certificate rollovers that occur periodically. The implementation went well, but we'll keep an eye on developments in this field to ensure everything continues to go smoothly.

Implementation

Using the excellent " hash-slinger " tools created by Paul Wouters from RedHat, it was easy to generate the TLSA record from the website certificate:

 $ tlsa --create --output rfc --usage 3 --certificate ripe.net.crt www.ripe.net
 _443._tcp.www.ripe.net. IN TLSA 3 0 1 6aef0c821fb98e13aa74bff193e9c3841403884d482a93acbc946157bb4a805c

N.B.: You may need to change the name field of the record and/or add a time-to-live field.

We then performed the changes in our zone and re-signed it. The result can be easily tested with dig:

 $ dig +dnssec +noall +answer +multi _443._tcp.www.ripe.net. TLSA @193.0.9.6
 _443._tcp.www.ripe.net.    300 IN TLSA 3 0 1 (
                 6AEF0C821FB98E13AA74BFF193E9C3841403884D482A
                 93ACBC946157BB4A805C )
 _443._tcp.www.ripe.net.    300 IN RRSIG TLSA 5 5 300 (
                 20151212100803 20151112090803 35970 ripe.net.
                 QhQG9QMjqaWUABCupsb0dPXf6uggf/rI8IeFkapR+RqE
                 dzDVp5C65nciVqUm7E0UCBpiS8OLNVLYyRomxHBDOSCH
                 sY9KxT2Du9uSB5Z6MBAgU7I3IG5FrvSh6/JKRm9H4vmN
                 v7XZaS7VvxT6F0E1hHZtDFpKtME1fUO+EJTrnaY= )

Validation tools

In order to validate the DANE records and actually make use of their added layer of authentication, there are a number of tools we can use. From the command-line, the aforementioned tlsa command also performs verification (however, note that it does not understand the wildcard notation in the hostname):

 $ tlsa --verify www.ripe.net
 WARNING: Name on the certificate (Subject: /C=NL/ST=Noord-Holland/L=Amsterdam/O=RIPE NCC/CN=*.ripe.net, SubjectAltName: DNS:*.ripe.net, DNS:ripe.net) doesn't match requested hostname (www.ripe.net).
 Caution: name on the cert does not match hostname
 SUCCESS (usage 3): The certificate offered by the server matches the TLSA record
 WARNING: Name on the certificate (Subject: /C=NL/ST=Noord-Holland/L=Amsterdam/O=RIPE NCC/CN=*.ripe.net, SubjectAltName: DNS:*.ripe.net, DNS:ripe.net) doesn't match requested hostname (www.ripe.net).
 Caution: name on the cert does not match hostname
 SUCCESS (usage 3): The certificate offered by the server matches the TLSA record

No browser supports DANE validation natively yet, but there is an add-on available for all major browsers: DNSSEC/TLSA Validator . During our testing the extension worked well, but it did increase browser instability when enabled (at least for Firefox). We hope that browser vendors will start supporting DANE validation by default and make it a standard feature as its use expands.

DANE Validation in Firefox DNSSEC/TLSA Validator in working in Firefox

Certificate rollover

In order to make sure that no validation errors would occur during certificate renewal and rollover, we have documented and applied the following system:

  1. The new SSL certificate is generated one month before the old SSL certificate expires.
  2. A new TLSA record for the new SSL certificate is added to the DNS zone file, keeping the old TLSA record as well.
  3. During the following months, either certificate will be considered valid by the browser.
  4. We perform the rollover and replace old SSL certificates.
  5. A week after the old SSL certificates have been replaced, the old TLSA records are removed from the DNS zone file.

Going forward

DANE is a new technology and many details still have to be worked out. We will keep track of developments in the field and update our set-up as improvements are implemented. Are you deploying DANE for your websites? Do you have any tips or suggestions for improvement? Please leave a comment and let us know!

7 Comments

Marco Davids says:
19 Nov, 2015 03:52 PM
Nice post!

ldns-dane also works nice:
http://manpages.ubuntu.com/[…]/ldns-dane.1.html

And here's a nice DANE-checker:
https://check.sidnlabs.nl/dane/
(there are others as well, but this one is ours)
Mihnea-Costin Grigore says:
20 Nov, 2015 10:47 AM
Thank you for the additional links, Marco, they are quite useful. The SIDNLabs checker looks very good!
Stéphane Bortzmeyer says:
27 Nov, 2015 05:09 PM
How do you monitor it? Is there a monitoring plugin for Nagios-compatible programs? I ask so because I really fear that people may update the certificate but forget about the DNS (it is typically two different teams). Procedures are OK but monitoring is better.
Mihnea-Costin Grigore says:
01 Dec, 2015 05:45 PM
Thank you Stéphane, you bring up a good point. Like everything surrounding DANE, monitoring is also a bit experimental at the moment so we're testing various approaches. There is a Nagios/Icinga plugin available: https://exchange.icinga.org/debfx/check_dane -- we're currently investigating it with the aim of production deployment.
Stéphane Bortzmeyer says:
02 Dec, 2015 09:06 AM
This article describes in detail the use of debfx with Icinga 2 to monitor DANE : https://www.d7031.de/[…]/
Drewbert says:
20 Sep, 2016 03:46 AM
Until the major browsers support DANE straight out of the box, DANE is a lame duck.

I can't see any sign of them doing so. The duck is not looking well.

Google is insisting on https. The CA's are smelling profit in the air.

Can't ICANN's SSAC do something about it?
Drewbert says:
20 Sep, 2016 11:22 AM
Evidence of the browser writers distain...

Searching https://wiki.mozilla.org/ for DANE gets you 7 results.

The latest one ( https://wiki.mozilla.org/MOSS ) mentions DNSSEC/DANE Chain Stapling

https://wiki.mozilla.org/[…]/09-18-13-NetworkTeam gives their 2013 opinion of Dane:

####
DANE?
I think we all agree it's not the right way forward
And slow
####

and in https://wiki.mozilla.org/NSS:BurnDownList ...

####
DANE is in the "Needs Definition / Prioritization" List
(Needs further definition, discussion, design, or prioritization before an engineer can implement it.)
Level of effort: To be determined
Notes: "Nice to have, but doesn't solve all the problems, and there is no commitment that a majority will use it."

####

So it's agreed then. Mozilla aren't interested?

How about Google Chrome?

https://bugs.chromium.org/p/chromium/issues/detail?id=50874

Some brave soul was an optimist at the start:

####
"i think it would be usefull to start implementing DNSSEC validation. there are libraries for this. For example: libval from http://dnssec-tools.org/ and minimalistic libldns from http://www.nlnetlabs.nl/projects/ldns/ (which i can really suggest to you)."
####

agl@chromium.org hammers the first nail into the coffin...

####
"We are considering our position with respect to DNSSEC. DNSSEC validation of A records and the like isn't useful and doesn't warrant any UI indication. DNSSEC validation of certificates may, but it would be premature to submit patches for that at this time."
####

Our optimist tries again...

####
It will be super-awesome if chromium will manage to get DANE support as technology-leading browser. DANE is really big step forwards for internet security...
####

someone else who had their account deleted tried to back him up...
####
Have there been any changes in the plans to include DNSSEC and DANE support in Chromium? It seems like this feature has been dead for a while now, given that DANE was standardized in RFC 6698 in 2012. It's been a few years and it seems like everybody has stalled in providing support for it.

I can't find a reference atm, but I believe that it was the ISC that said that some 45-50% of SSL certs used in the wild are self-signed; widespread support and deployment of DANE/DNSSEC would go a long way of providing security to the users of those 45-50% of SSL certs. I would love if Chrome would lead the world in providing production-quality client support for DNSSEC and DANE.
####

Then the nail is hammered home...

####
Closing this out as WontFix, as there are no plans.

The ISC number is not accurate for what real world users experience, and is biased by crawls that have a number of experimental limits.

DNSSEC and DANE (types 2/3) do not measurably raise the bar for security compared to alternatives, and can be negative for security.
DNSSEC+DANE (types 0/1) can be accomplished via HTTP Public Key Pinning to the same effect, and with a much more reliable and consistent delivery mechanism.

While not desiring to stifle discussion, we've continued to evaluate the security and usability benefits and costs of DNSSEC and DANE, and will continue to do so, but for now, this is neither something we plan to implement nor would support landing.
####

So is the status for FireFox and Chrome still this?

If so, all the hard work put into DANE and ICANN's implementation of DNSSEC seems to have all been a waste of time?
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.