+++
title = "DNSSEC + DANE: Part 1"
date = "2013-09-14"
tags = ["security", "technical", "DANE"]
+++

#### Problem

Communications on the Internet overwhelmingly rely on SSL/TLS for protection.
There are two forms of protection this is meant to provide - from snooping of
traffic, and from impersonation. The first of those gets a lot of attention
but, unless we have the latter as well, an attacker can snoop on your traffic
by [performing a man-in-the-middle attack on you with a dodgy 
certificate](http://falkvinge.net/2013/09/12/the-nsa-and-u-s-congress-has-destroyed-ssl-we-must-rebuild-web-security-from-the-ground-up/).

Unfortunately, the current method of providing protection-from-impersonation
is terrible. Traditionally, OS and browser vendors pick a range of root
certificates to bundle with their software - a list that's generally hundreds
of entries long - and everyone trusts that the list is good. Anyone who can
get a certificate into the lists can then sell certificates signed by it to
people who can't (like me, for a start).

They can sell certificates for any domain, for any reason, with any degree of
publicity, transparency or validation; the only recourse vendors have is to
threaten to stop trusting them if the're shown to be issuing certificates that
don't meet some standard or another. If they're compromised and the key for the
root certificate is stolen - 
[as happened in 2011](https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https)
- then it's a mad scramble to revoke or blacklist new certificates based on that
stolen information before too much harm is done.

Recently, some vendors - Chrome, for instance - haver started introducing 
[certificate pinning](https://www.imperialviolet.org/2011/05/04/pinning.html)
to restrict the range of CAs that are valid for a particular domain. This helps
a bit against some attacks on large sites, but isn't much use as a general
solution.

As for the first part - the encryption itself - there's a lot of discussion
right now over which parameters are safe, and which aren't. There's probably
*some* setups that're safe from cryptanalysis - or if not, then we can probably
come up with some. In this area, one more problem we have with the current CA
model is that deploying new types of certificates is a slow process - you have
to wait for a trusted CA to start offering them, before you can use them.

#### Solutions


The current system, then, can be summarised as trust silos. The main contender
to replace it is an RFC known as
[DANE](https://datatracker.ietf.org/doc/rfc6698/).
This leverages DNSSEC-signed DNS to publish records that say which certificates
(rather than certificate authorities) are valid for a particular service running
on a domain. As it utilises the DNS, we move from trust silos to hierarchical
trust.

Hierarchical trust is narrower, and so better, but still vulnerable to
compromises of keys not under your control. However, the only other schemes
I'm really aware of at the moment are based on web-of-trust relationships with
offline identity verification. This boils down to everyone manually curating
bookmarks that tell them how much to trust things, and there are still keys
out of your control that, if compromised, break you - you just get to choose
between trust anchors more flexibly than with a hierarchical system. I'm not
convinced the extra effort is worth it, so I've deployed DNSSEC + DANE instead,
and in the next article, I'll go over how I did it.

