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.

No, it's not simply a rhetorical device.

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?

DLV: "Screw ICANN, I'm going to build my own DNS, with blackjack and hookers."

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.

Some previous discussions

https://news.ycombinator.com/item?id=2939002 http://tawqer.com/comment/12538720#.U2Ql4IL7HIE https://news.ycombinator.com/item?id=1234721

Djb on dnscurve, a better way: http://marc.info/?l=djbdns&m=129434351607605&w=2 https://news.ycombinator.com/item?id=2078475

and others.

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.

[^2]: High-speed cryptography and DNSCurve, pg 26-27. http://cr.yp.to/talks/2009.06.27/slides.pdf

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.

You think a silly, hipster domain hack is more important than countries having control over their own national TLDs?