
Some bad news for DANE and DNSSEC - okket
https://blog.apnic.net/2019/05/27/dns-oarc-30-bad-news-for-dane/
======
cjbprime
> certificate transparency logs appear to be completely ineffective in
> catching CA-related name hijack events in real time.

In what sense is this true? They're effective because browsers only accept
certs which can first prove that they were submitted to a CT log, and it's
easy to search the CT logs for e.g. gmail.com to find potential misissuance
events.

This is the first time I've heard CT described as ineffective. What gives?

~~~
agwa
It's unclear what Huston means by "real time", but in the comments section he
cites the fact that it took 6 months for the misissued Symantec certificates
for example.com to be noticed.

That's because the owner of example.com wasn't monitoring CT. Had they been
monitoring, they would have been alerted quite quickly. As a case in point,
when Certinomis misissued a certificate for test.com, my monitor notified me
16 minutes after issuance, I filed a report with Mozilla two hours after
issuance, and a representative of Mozilla responded less than 3.5 hours after
issuance.[1] That's pretty fast.

And now Mozilla is kicking Certinomis out, providing yet another example of
how CT is improving the Web PKI. CT works.

[1]
[https://bugzilla.mozilla.org/show_bug.cgi?id=1496088](https://bugzilla.mozilla.org/show_bug.cgi?id=1496088)

~~~
rurounijones
That was really interesting to read. As a relative layment in this area. Do
you have any recommendations on reading material in this area? How is your
monitoring setup?

~~~
tialaramex
An earlier edit of your post seems like you didn't understand enough about how
X.500 Distinguished Names work to search the DNs (presumably in crt.sh) so
learning about that might not be time wasted if you care what's inside a
certificate other than domain names. Be warned that although the CAs are
required by CA/B rules to get most of those other details right when they're
included there is limited appetite for enforcing such a rule.

There are Google Groups (because a lot of this is a Google project or spins
out of Google projects) for a lot of this, including
mozilla.dev.security.policy (the public discussion of Mozilla's root trust
store policy), certificate-transparency (general discussion of CT) and crtsh
(discussion of Rob's crt.sh monitor database and site). They're all usually
quiet enough that you could read back a few months and/or subscribe and have
them in your background.

~~~
rurounijones
Yes, sorry abut the edit, I thught I was quick enough to ermove it before
anyone read it as I figured out what I was doing wrong.

Thank you very much for the links.

------
theamk
> The efforts of the CAB Forum to instil some level of additional trust in the
> system appear to be about as effective as sticking one’s fingers into a
> leaking dam. The number of trusted CAs has extended conventional credibility
> well beyond the normal boundaries and has pushed the unsuspecting user into
> a fragile state of credulity.

> Efforts to improve this mess, such as Extended Validation (EV) certificates,
> have gained no traction with users, as they are largely immune to subtle
> changes in the content and colours of the browser’s navigation bars, and
> certificate transparency logs appear to be completely ineffective in
> catching CA-related name hijack events in real time.

That’s a pretty extreme opinion. I am surprised it appeared on official
apnic.net site. I do wonder if it has anything to do with the fact that most
major browsers, who actually decide who get to be CA, are US based.

~~~
throwaway2048
Its hardly extreme, your browser quite literally trusts hundreds of CAs.

How much do you trust:

GUANG DONG CERTIFICATE AUTHORITY

Turkiye Bilimsel ve Teknolojik Arastirma Kurumu - TUBITAK

Unizeto Sp. z o.o.

XRamp Security Services Inc [1]

AC RAIZ FNMT-RCM

etc, To have not been compromised, or selectively delivering certs to
"interesting" targets. Because they can tell you practically any host on the
internet is a valid SSL domain.

Stuff like DNS CAA records, and certificate transparency help somewhat, but
are either trivially stripped by MITM attacks or not implemented at the CA or
software level.

[1] Appears to have went out of business entirely, how safe is that SSL cert
now?

~~~
tptacek
As Adam Langley has observed, fully implementing DANE doesn't get rid of these
"hundreds of CAs", but rather adds a hundredsth-and-first --- the DNS
hierarchy.

[https://www.imperialviolet.org/2015/01/17/notdane.html](https://www.imperialviolet.org/2015/01/17/notdane.html)

Meanwhile, CT has done more to protect the Web PKI in a couple years than
DNSSEC ever has, and without forklifting out infrastructure. In fact, if
rumors are true and at least some of the CA misissuance was detected due to
broken pins, you can say the same thing about HTTP certificate pinning, and
that technology wasn't even successful.

~~~
cryptonector
It adds one more, yes, but it is exclusive. That is, if a domain wants to use
DNSSEC and DANE, then that is mandatory for clients that support it, and for
them WebPKI becomes a non-issue.

The fact that DNSSEC is a true PKI, and the only true Internet-scale PKI, and
one that is 100% aligned with the domainnames that users understand and which
are embedded in URIs and email addresses, and the fact that DANE gives one a
way to opt out of the WebPKI mess -- that all makes DNSSEC/DANE superior.

~~~
tptacek
If someone today wanted to use DANE exclusively, opting out of the rest of the
Web PKI, what percentage of Internet users would be able to make HTTPS
requests to their site?

~~~
comex
If browsers someday decide to implement some DANE-like feature, it would
quickly become a fairly high percentage. There would still be a rather long
period where browsers would have to continue to trust Web PKI certificates in
general, even assuming they decided to phase them out. But... during that
time, anyone using DNS over HTTPS with a trustworthy resolver would presumably
get the right TLSA records, so their browser would reject attackers’
certificates even if validly signed by the Web PKI, no?

~~~
tptacek
That's an answer to the "hypothetical someday" question, but I'm interested in
what the number would be today.

~~~
comex
Then the answer is approximately 0%, right? But what does that prove? Perhaps
DANE is not ready yet, or perhaps it’s struggled to get adoption because its
design is fundamentally flawed; you’re versed on the details, I’m not. But to
me that seems pretty orthogonal to whether “adding one more” is good or bad,
or whether DANE’s design is fundamentally superior to the CA model as
cryptonector claims. Or at least it’s a very oblique way to make a point about
that.

~~~
tptacek
My objection, which, mea culpa, I stated obliquely, is to 'cryptonector's
subtext that DANE is a reasonable thing for an actual operator to pursue in
2019. We can't even generate a workable draft for _how_ a browser would
implement DANE in 2019, let alone see it implemented in a browser. Huston is
probably right that the failure of this draft takes DANE off the table for
another couple years† --- a couple more years in which DNSSEC can't do the one
thing DNSSEC people think it's most valuable for.

How many years have to pass before we give up on this boondoggle? We're coming
up, within this next 12 months, on _twenty five_. Do we wait for year thirty
to finally, formally declare time of death? I'm fine either way. But I'd say
we passed the mark where people can casually pretend that DANE is something
anyone should expect to get value out of at least five years ago.

So I take umbrage at the tone of that comment above, that "it's OK that DANE
adds one more CA to the mess of CAs we already have because some people will
lock their sites down to DANE-only". Well, no, no they won't, because that's
akin to taking your site off the Internet, and that will remain the state of
play indefinitely (probably forever).

† _and that assumes that after the IETF figures out how to specify stapled
DANE that the major browser vendors will adopt it; the evidence points the
other way._

------
tptacek
This is a long and interesting summary of a DNS operations research workshop.
The "bad news" bit is just one part of it.

The "bad news" here is that the TLS dnssec-chain-extension was dropped by tls-
wg. Chain-extension staples DNSSEC records to TLS handshakes, so that you
don't need to do extra DNS lookups to get them. This is important because a
pretty big fraction of Internet users are on networks that can't reliably look
up DNSSEC records using the actual DNS protocol.

If you're hungry for the details (of course you are!), I believe they can be
summed up as follows:

1\. The point of dnssec-chain-extension is to enable browsers to use DANE,
either as an alternative or an enhancement to the X.509 CA hierarchy.

2\. That means the threat model for dnssec-chain-extension has to include
attackers with valid certificates; define them out of the threat model and
you've defined DANE out of having a point.

3\. An attacker with a valid certificate can strip dnssec-chain-extension out
of a TLS handshake.

4\. So they had to reinvent certificate pinning to make dnssec-chain-extension
make sense.

5\. But certificate pinning is already a dead letter as a browser standard,
because of operational concerns around abuse and also consequences of
misconfiguration.

If you're just here for another dose of my DNSSEC snark, I will observe for
you this: Geoff Huston, a giant in the Internet/DNS operations research
community, concedes in this post that DANE is the whole "reason DNSSEC is
worth the effort". He also believes that dnssec-chain-extension was vital to
getting it deployed in browsers (I'm skeptical Google, Microsoft, or Apple
were going to dip their toes in this swamp-water again, but whatever). And
Huston apparently didn't notice until today that the tls-wg killed this draft
last year.

If you're keeping score, the DNSSEC "stick-a-fork-in-it-ometer" is currently
registering:

* The elimination of DNSSEC from macOS, Mozilla, and Chrome (in that last case accompanied by a statement about why the team doesn't believe DANE is workable).

* The success of DNS-over-TLS and DNS-over-HTTPS, both of which accomplish 96% of the bottom-up, fuck-DNSSEC goals of DNSCrypt (or whatever it was Dan Bernstein called it).

* The success of Certificate Transparency and, more broadly, Google's success at cracking down on CAs and getting CT deployed, which further deflates the impetus for DANE.

* LetsEncrypt (and, I guess, Amazon's Certificate Manager), which took money out of this whole contest (I don't think money was ever the big deal in the real world that IETF people thought it was, but it sure drove a lot of dumb mailing list posts).

* MTA-STS, the SMTP strict transport security system that locks down TLS between MTAs, which was standardized by all the major email providers, specifically (stated in the draft!) to avoid the need for DNSSEC, and which is now being rolled out at GMail.

* And now I guess we'll pretend that DANE in browsers was somehow on the table and that it just died. I'm just happy we agree it's not happening.

I don't think I'm quite ready to stick a fork in it, but it's getting close.

My favorite detail from this writeup, by the way, is the fact that Sweden and
the Netherlands got their DNSSEC adoption by paying people to use the
protocol.

~~~
jaas
Money is a big deal for ease-of-use and access. Tracking down a credit card
and the necessary approvals to use it, even if the amount of money is no big
deal, is a lot of friction for many people. Could be corporate red tape, could
be that you don't have a credit card. Could be because you're in a country
where financial sanctions prevent you from transacting with a foreign CA.

All of this friction would lead to many sites not using HTTPS because it's
just too much of a hassle. And it's the visitors to those sites that suffer
most.

~~~
tptacek
TLS certificates are free now and that is unlikely ever to change again.

~~~
jaas
You stated that it wasn't a problem before they were free:

"I don't think money was ever the big deal in the real world that IETF people
thought it was, but it sure drove a lot of dumb mailing list posts"

I am pointing out that I disagree, it was a very big deal and it's why I
created Let's Encrypt.

~~~
tptacek
I think Lets Encrypt is a big deal. I think making TLS certificates free is a
big deal in terms of getting people to deploy HTTPS. I don't think they're a
big deal in terms of getting people to use some other protocol like DNSSEC
instead. Sorry, I worded that imprecisely.

------
skywhopper
Not sure I see how making easily-hijackable DNS the authority for TLS
certificate trust would solve these problems. In fact, I would expect that
would make it worse, by putting all your eggs into one basket.

~~~
amluto
It’s _already_ the authority for TLS trust. How do you think domain validation
works?

~~~
icedchai
Yep. Let's just cut out the middlemen already.

------
ryacko
Any change in how PKI is used in a browser must be done by browser vendors, no
change has been their decision.

The idea spread that TLS should be used after Snowden is a bizarre
antipattern. HTTP cache appliances have been rendered obsolete, and domain-
validated certificates only provide assurances that you are connecting to the
same server that LetsEncrypt had connected to.

