
The DNS-Based Authentication of Named Entities (DANE) TLS Protocol - garaetjjte
https://tools.ietf.org/html/rfc6698
======
okket
OpenSSL 1.1.0 gained support for DANE TLSA peer authentication.

    
    
      Obtaining and performing DNSSEC validation of TLSA records is
      the application's responsibility.  The application provides
      the TLSA records of its choice to OpenSSL, and these are then
      used to authenticate the peer.
    
      The TLSA records need not even come from DNS.  They can, for
      example, be used to implement local end-entity certificate or
      trust-anchor "pinning", where the "pin" data takes the form
      of TLSA records, which can augment or replace verification
      based on the usual WebPKI public certification authorities.
      [Viktor Dukhovni]
    

Changelog:
[https://www.openssl.org/news/cl110.txt](https://www.openssl.org/news/cl110.txt)

API:
[https://www.openssl.org/docs/manmaster/ssl/SSL_dane_enable.h...](https://www.openssl.org/docs/manmaster/ssl/SSL_dane_enable.html)

The RFC for storing/lookup OpenPGP keys in DNS via DANE was published
recently:

"DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP"

[https://tools.ietf.org/html/rfc7929](https://tools.ietf.org/html/rfc7929)

All documents from the DANE working group are here:

[https://datatracker.ietf.org/wg/dane/documents/](https://datatracker.ietf.org/wg/dane/documents/)

Edit: Since there is lot of negativity towards DNSSEC here, please have a look
at the following link, so you get both sides of the arguments

[http://blog.easydns.org/2015/08/06/for-
dnssec/](http://blog.easydns.org/2015/08/06/for-dnssec/)

------
eloy
_rant about DANE from tptacek incoming_

[http://sockpuppet.org/blog/2015/01/15/against-
dnssec/](http://sockpuppet.org/blog/2015/01/15/against-dnssec/)

I don't have a strong opinion on DNSSEC myself, but I agree with him that DANE
is a bad replacement for standard TLS connections. DNSSEC is by far not the
best security protocol ever designed, but it can protect to some threats, like
cache poisoning.

~~~
tptacek
Honestly, while I do truly believe that DANE is an insane response to the
Snowden disclosures that centralizes Internet trust and hands the keys over to
the FVEY IC, that's _not_ my biggest problem with DNSSEC. It's just the
argument that I think has the strongest valence on HN.

Most of that post isn't about NSA controlling the Internet. It's about what a
mess DNSSEC is, and how little it does to protect anything on the Internet
even in a universe where it's actually deployed.

~~~
0x0
But in today's world where CAs issue certificates based on simple DNS A and MX
record lookups for ownership verification, whoever controls the root zone or
the relevant TLD zones can get "the keys" they want already.

~~~
tptacek
First, nobody believes any part of the FVEY IC can't already get TLS
certificates. DNS spoofing? They've already got CA=YES certificates.

Second, DNSSEC doesn't even prevent this attack! All it does is attempt to
protect name lookups. SMTP itself doesn't magically become secure just because
there was a signature on an A record.

Finally, we're already doing something that meaningfully blunts this attack.
No matter how the CA system is compromised, browsers still monitor certificate
pins. When pins break, the CA associated with the malicious certificate gets
reported. When that happens, as we've seen repeatedly, the CA gets penalized
--- or put out of business entirely.

Public key pinning, CT, and surveillance is _actually_ making a dent in the
Internet trust problem. DNSSEC is a charade --- or, I think, something worse
than that: you can't simply "revoke" .COM.

~~~
0x0
Maybe we could

1\. take away all the existing CA=YES certificates

2\. stop using SMTP for domain verification, and issue the certificate at the
same place that a domain's NS records are set (i.e. in a domain registrar's
control panel), preferably in way that clients won't accept certificates
issued by unrelated (and there unauthorized) domain registrars.

As I mentioned the other day, nobody is talking about revoking ".com". We'd
have multiple registrars under ".com", and if one behaves badly, revoke that
particular registrar. Also, if ".com" itself is out to spoof you, then you
have already lost as a .com domain owner, so maybe we SHOULD revoke all of
.com if proof of that surfaces, so that everyone will know that .com can't be
trusted at all anymore.

~~~
tptacek
Maybe we could actually fix the problem instead of just moving it around.

------
nneonneo
This RFC was proposed in 2012. It provides a simple way to place TLS server
certs in DNS, in addition to or even in place of usual TLS certificate
negotiation. In theory, it lets us even remove the TLS chain of trust in favor
of the one provided by DNSSEC.

However, it is obviously dependent on DNSSEC, and as the latter isn't quite
ubiquitous yet, DANE cannot be widely deployed.

------
stephenr
Whenever DANE comes up, DNSSEC in general comes up.

Whenever DNSSEC comes up, a raft of people arrive to say "but this means the
government will have complete control and can do what they want".

The evidence of this actually being a reality is then given as the us
government took down a known and acknowledged "piracy" site.

A further example is given that e.g bit.ly would have been effectively
controllable by Gadafi.

First off: no one forced them to use the .ly domain. If you choose to use a
country code domain you should be aware of the situation the controlling
country is in.

Second: if your _only_ argument supporting the idea that democratic
governments - even those as fucking ass backwards as the USA - will
arbitrarily take control of your domain, is a file sharing site, I suggest you
look for more evidence.

------
tptacek
For those unaware:

DANE is a scheme whereby TLS certificates are stored in DNSSEC-signed DNS
records.

The conventional nerd wisdom is: this is fantastic, because it's a step
towards replacing the totally broken CA system with something that technical
people can take direct control over. I like that story too.

Unfortunately, _the conventional wisdom is totally wrong_. DANE does not
eliminate CAs. Even in a world where DANE is universally deployed in all
browsers ( _no_ browser does it today --- and several tried, and then removed
support), we will still have CAs. What DANE will give us is a bunch of new
CAs: one for every TLD, and one at the root. Don't take my word for this: Adam
Langley, TLS superhero of the Chromium team, wrote an excellent blog post
explaining why.

But it gets worse. Those new CAs DANE deployed? They are controlled
overwhelmingly by world governments. The most popular DNS TLDs are all legally
bound to the governments of the FVEY IC. Here again you don't have to take my
word for it: all you have to do is look at what the DOJ did to file sharing
sites by asserting its control of the DNS.

Lots of things are happening behind the scenes to make the train wreck of
Internet trust a little better:

* CA certificates themselves are hurtling towards "free", especially now that we have Let's Encrypt

* Major browsers are implementing HPKP and static key pinning, so that once you see a certificate for a pinned domain, your browser remembers and screams bloody murder if it changes unexpectedly. Someone who attempts to get a domain-validated certificate to hijack Google Mail will, in the best case, succeed only in getting the CA dumb enough to do that kicked out of the Chrome and Firefox root trust store.

* Google and others are coordinating efforts to monitor certificate issuance, not just using certificate pins but also with initiatives like Certificate Transparency, which involves cooperation from CAs that Google has repeatedly shown willingness to require as a condition of being included in their trust store.

DNSSEC is not one of those things. It's a broken protocol, an attempt to
deploy decades-outmoded cryptography across the backbone of the Internet, and,
in the very best case, a bit of security theater.

This, to me, is one of the rare cases where I think random end users who
aren't in the unofficial cabal of TLS library maintainers, ISP operators, or
standards committee members can make a real difference in Internet security.

 _Don 't let people pretend that DNSSEC is a good thing just because the name
ends in SEC_. When you see people cheerleading DNSSEC deployments, _challenge
them_. DNSSEC deployment is failing, and has been failing for something like
15 years now. Let's try to keep it that way!

~~~
zeveb
> Those new CAs DANE deployed? They are controlled overwhelmingly by world
> governments.

As opposed to all the other CAs, which are _also_ controlled by governments.
Every CA has some person or group of people who are able to cause certificates
to be issued, and that person or people can be compelled to produce
certificates at the whim of their government.

> CA certificates themselves are hurtling towards "free", especially now that
> we have Let's Encrypt

Not that Let's Encrypt's security model is … to trust unsecured DNS. So it's
strictly worse than DNSSEC.

> * Major browsers are implementing HPKP and static key pinning, so that once
> you see a certificate for a pinned domain, your browser remembers and
> screams bloody murder if it changes unexpectedly. Someone who attempts to
> get a domain-validated certificate to hijack Google Mail will, in the best
> case, succeed only in getting the CA dumb enough to do that kicked out of
> the Chrome and Firefox root trust store.

I think pinning is orthogonal to DNSSEC: one might implement both DNSSEC and
it.

> * Google and others are coordinating efforts to monitor certificate
> issuance, not just using certificate pins but also with initiatives like
> Certificate Transparency, which involves cooperation from CAs that Google
> has repeatedly shown willingness to require as a condition of being included
> in their trust store.

One might, of course, do the same thing with DNSSEC, and then come to
understand which nation-states actually _do_ break DNS and which refrain from
doing so, rather than spreading FUD about them.

~~~
tptacek
I'm sorry, I'm a little lost at "the solution to governments having captured
individual CAs is to add a set of new CAs that they control directly and that
can't be revoked because they're tied to the DNS".

~~~
zeveb
> I'm sorry, I'm a little lost at "the solution to governments having captured
> individual CAs is to add a set of new CAs that they control directly and
> that can't be revoked because they're tied to the DNS".

That's because it's not a solution. There isn't a non-political solution.

By making it explicit rather than implicit one is forced to confront the
truth, and be honest about it. _.com is owned by the United States;_.ru is
owned by Russia; _.ly is owned by Libya;_.io is owned by the United Kingdom.

If we got rid of non-DNS CAs (for host-verification purposes, anyway), it
_would_ , however, mean that _only_ the U.S. may legally suborn _.com,_.org
&c.; that _only_ Russia may suborn *.ru, and so forth. That's a pretty big win
over the present situation, in which every government who can lay its hands on
a CA employee can get a certificate for any site in the world.

~~~
tptacek
People keep saying this in response to ".COM is owned by the USG no matter
what" and it's _not true_.

The USG's ownership of .COM does _not_ in fact enable them to intercept Google
Mail requests. The reason it doesn't is that if you get a CA to issue a bogus
Google Mail request for surveillance purposes, _Google will put your CA out of
business_.

Chrome has mid-high double digit market share. No matter what the DNS
hierarchy says, and no matter what some random CA says, Chrome ships knowing
what a valid certificate for Google Mail looks like. When you try to tell
Chrome something is a Google property that isn't, Google finds out, and they
take action.

It used to be they only did this for non-Google properties if you asked them
nicely. But now there's a protocol that automates it, called HPKP.

HPKP does not give a fuck what government is currently in power in Libya. If a
CA starts issuing bogus .LY certs, that CA probably isn't going to be issuing
certificates for .LY --- or many anything else --- for much longer.

This helps _everybody_ , not just the people running Chrome. IE doesn't
support HPKP. But every single person running Chrome is participating in a
certificate surveillance system that will light up if someone makes the
mistake of feeding them a bogus cert.

Google is also getting the ball rolling on Certificate Transparency, which
directly monitors all certificate issuances from participating CAs. Browser
vendors have shown a willingness to force CAs to participate if they make any
mistakes at all.

This is a problem that is in the process of being solved. DNSSEC is a
MONUMENTAL STEP BACKWARDS. Thankfully, it isn't going to happen, but we can
make that not-happening even clearer and faster by noticing when people talk
positively about DNSSEC and then challenging them.

~~~
garaetjjte
Deploying DANA doesn't mean that we can't use HPKP. It is independent
solution.

> Chrome has mid-high double digit market share. No matter what the DNS
> hierarchy says, and no matter what some random CA says, Chrome ships knowing
> what a valid certificate for Google Mail looks like. When you try to tell
> Chrome something is a Google property that isn't, Google finds out, and they
> take action.

And this situation won't change with DANA.

> HPKP does not give a fuck what government is currently in power in Libya. If
> a CA starts issuing bogus .LY certs, that CA probably isn't going to be
> issuing certificates for .LY --- or many anything else --- for much longer.

If they control DNS for domain, they can change MX records for verification
and buy certificate in any legitimate CA.

~~~
tptacek
DANE _does_ harm HPKP. Part of the point of HPKP is that when pins are broken,
browsers can punish CAs. You can't punish the TLDs that way. HPKP assumes
agility. DANE removes agility.

Equally importantly: DANE doesn't actually solve any problem we have today.
HPKP does. Why would you spend a penny, let alone tens of millions of dollars,
to deploy something that is a step backwards for our security? What's the
point?

Regarding MX records: I think you need to re-read the post, its FAQ, or the
comments on this thread, because it's been addressed _ad nauseam_.

~~~
garaetjjte
With DANE there will be no CAs, so yes, there will be no CAs to punish. But
owners of root zone can already change DNS records to buy certificate in any
CA, and you cannot punish them for that because they aren't required to do any
validation above checking DNS records for non-EV certs.

In worst case DANE is equally secure as current CA system (ok, except that
weak RSA, but I hope it will be fixed soon). Why you want to keep CAs, when
you have to waste resources on constantly monitoring and punishing them, while
with DNSSEC you can ditch them? In both systems DNS root zones owners can
buy/generate certificates for child zones. This was also addressed _ad
nauseam_.

~~~
tptacek
At this point we're just repeating ourselves, so I think we're done.

------
jakobdabo
Is it an insane idea to incorporate the blockchain technology into the current
PKI system so that every time a CA signs a key it must insert a new
transaction into the blockchain which links it to the certificate? We could
have a full, transparent and cryptographically secure certificate log.

~~~
lziest
check out certificate transparency [https://www.certificate-
transparency.org/](https://www.certificate-transparency.org/)

~~~
jakobdabo
That's not quite the same, but I just found this NeoDNS[0] proposal, and it
seems to be just what I described.

[0] [https://rot256.io/post/neodns/](https://rot256.io/post/neodns/)

edited: Apparently it was briefly discussed at HN only 2 days ago:
[https://news.ycombinator.com/item?id=12370146](https://news.ycombinator.com/item?id=12370146)

