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?
One 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.
DNSSEC'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?
I 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."
You 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.
You 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.
It is a little difficult to figure out what you are trying to say when the bulk of your comment is "invoke other people's words." Initially it seems that you are a proponent of DNSCurve but you directed my attention to a link that highlights a fault of DNSSEC and DNSCurve. You linked to a page[^1] pointing out that:
> Libya(!) controls .ly. If DANE had been successful a few years
> ago, Ghaddafi's government would have controlled bit.ly's certs.
Yes this is a problem for DNSSEC but it is also a problem for DNSCurve. Let's refer to one of djb's slides[^2] and substitute bit.ly for ubuntu.com:
> How does DNSCurve client retrieve server’s public key?
> DNS architecture: DNS client learns IP address of .bit.ly DNS
> server from .ly DNS server.
> The .ly server says: “The bit.ly DNS server is named petard and
> has IP address 666.1.0.3.”
> The name petard was selected by the bit.ly admin and given to .ly.
> To announce his DNSCurve server’s public key, the bit.ly admin
> changes the name petard to an encoding of the public key.
> The DNSCurve client sees the public key, begins cryptographically
> protecting communication with that server.
It seems that the Gaddafi problem is bad for DNSSEC and DNSCurve. The zone pinning via DLV in dfc's fuster clucked DNS (dfcDNS) neutralizes the Gaddafi problem at the cost of an absolute ops nightmare. It is worth noting that dfcDNS would pick a better name for the nightmare distribution service than itar.iana.org. Why someone thought it was a good idea to remind people of the cryptowars is beyond me. Maybe ITAR was a bad joke by someone at IANA?
[^1]: I recognize the author, but that is irrelevant. In fact I am not sure
that the author would want to bring up this problem in the context of this
discussion.
Compared to the U.S. Gaddafi was a saint. I know you yanks have been brainwashed, but he was nowhere near as bad as your demagogue policitians and media would have you believe. Likewise for the other few dozen world leaders and revolutionaries the U.S. have murdered.
[^1]: https://news.ycombinator.com/item?id=7615911