3 ms·
> Sign it over to the government This is already something I do not like about the CA system. I do not understand why people talk about DNSSEC as if it is mor
by dfc 13y ago
> Sign it over to the government
This is already something I do not like about the CA system. I do not understand why people talk about DNSSEC as if it is more of a land grab by government than the currently deployed CA trust model. The last time[^1] this came up it seemed like we agreed that the CA infrastructure and DNSSEC are essentially the same when it comes to nation-state involvement/interference/infestation. Is the "sign it over to the government" bit merely a rhetorical device employed to drive the point home or has something changed?
[^1]: https://news.ycombinator.com/item?id=7615911 https://news.ycombinator.com/item?id=7615911
- tptacek 13y agoOne difference between the CA system and DNSSEC w/r/t/ government dependence is that DNSSEC's dependence on government fiat is explicit and de jure, and the CA system's is implied and de facto. Another difference between CA and DNSSEC government dependence is that DNSSEC is, as I said, baked into the core of the Internet; it sets policy for name resolution. It's difficult to override decisions made by DNS/DNSSEC. The same isn't true of the CA system; for instance, everyone using Chrome and Firefox is routinely overriding the CA system when they use Google Mail. No, it's not simply a rhetorical device.
- dfc 13y agoDNSSEC's explicit reliance on government is dependent on ICANN's MoU. The role of government is a lot different when using ISC's DLV. Is pinning gmail's cert any different than using a google supplied DLV key?
- tptacek 13y agoDLV: "Screw ICANN, I'm going to build my own DNS, with blackjack and hookers."
- dfc 13y agoI know it sounds a little goofy and I am not trying to be difficult just to be a dick, it was a genuine/good-faith response. Is it really that different than: Cert Pinning: "Screw the CA cabal, I'm going to build my own PKI, with blackjack and hookers." Certificate pinning only works when I interact with gmail via FF/Chromium on port 443. When postfix connects to gmail over 25/465/587 we fall back to the CA-cabal if (a big if) postfix is configured to verify certificates. We can take the madness full circle: DLV+DANE: "Screw pinning certs in the browser, I'm going to pin all the things, with blackjack and hookers."
- tptacek 13y agoYou have me at a disadvantage as I had a wisdom tooth pulled just an hour or two ago, but I'll point out that having multiple different CA policies is actually not that big a deal (witness that we do that today with pinning), whereas running multiple DNS lookaside policies is an operations clusterfuck.
- dfc 13y agoYou have me at a disadvantage because you probably had more wisdom in the one tooth about these things than I do in total;) I think the reason that cert pinning is "not that big of a deal" is that it only works for a small number of organizations, on a small set of applications, for one of 65,535 ports. The cert pinning system does not work for billybobsblog.com, is not implemented in wget/curl/ruby/python and does not protect my gmail data over 25/143/465/587/993. Yes, "pinning all the things" with DANE+DLV would be a giant clusterfuck but that is simply because it is cert pinning writ large. Fixing the damn is always a clusterfuck compared to sticking a thumb in the most conspicuous leak and calling it a day. I don't want to drag this on any longer than needed.[^1] I hope that the dental recuperation is uneventful. If it is any consolation I got a chuckle imagining C.J. Craig from the West Wing reading your messages right after her "woot can-owl surge-ah-wee." [^1]: The next time DNSSEC comes up (and it will) I would like to get your take on how you think the problems with names/certificates compare to those described in "Reflections on Trusting Trust." It seems like trusting everything down to the bare metal is only a tad more Sisyphean.