I've never understood the criticism that DNSSEC places control of TLS keys with governments - it seems like they already have that control. For example, Libya could change the dns records for bit.ly and get a certificate. I suppose an EV certificate with offline verification might help that, but you could use those with DANE, but DANE doesn't seem any worse than domain or email validated certificates.
I think the issue isn't that this is somehow worse but simply that DNSSEC is redundant to the fixes which we already need to make (e.g. public key pinning) so you're left with the question of deploying something which doesn't make you more secure and does provide a new way for things to break.
Can you expand further on the problem which you see? Pinning appears to address the biggest problem with the current CA model, where any of the CAs are equally valid, by allowing you to pick the CA(s) used and, if desired, even locking it to a specific host certificate:
> To perform Pin Validation, the UA will compute the SPKI Fingerprints for each certificate in the Pinned Host's validated certificate chain, using each supported hash algorithm for each certificate. (As described in Section 2.4, certificates whose SPKI cannot be taken in isolation cannot be pinned.) The UA MUST ignore superfluous certificates in the chain that do not form part of the validating chain. The UA will then check that the set of these SPKI Fingerprints intersects the set of SPKI Fingerprints in that Pinned Host's Pinning Metadata. If there is set intersection, the UA continues with the connection as normal. Otherwise, the UA MUST treat this Pin Validation Failure as a non-recoverable error. Any procedure that matches the results of this Pin Validation procedure is considered equivalent.
Unless I'm missing something, that allows you both to limit the number of CAs which you trust and if you go to the trouble of pinning specific certificates you can even limit damage from a compromised CA.
It doesn't scale, as the above spec points out. Pinning could be used to eliminate CAs (as most people initially expect) but this isn't viable at the moment. The specification, which proposes a method to validate the certificate chain, also accomplishes very little: it's fully vulnerable to MITM attacks on the first client connection. There are also privacy concerns about storing pinning data; and a browser which is configured to clear all data at exit would not see any benefit.
It's also wrong to say that public key pinning (which addresses PKI/TLS weaknesses) makes DNSSEC redundant. I suppose the proper comparison would be to the (optional) DANE?
> It's also wrong to say that public key pinning (which addresses PKI/TLS weaknesses) makes DNSSEC redundant. I suppose the proper comparison would be to the (optional) DANE?
It wasn't so much specific to pinning as a general thought that most sites will be in the situation where they need to deploy the TLS-specific measures because they have too many clients which can't assume DNSSEC but if you're already doing that, it's not clear to me that many places would see enough additional value deploying something which is less mature and harder to manage. This is particularly a big deal for anyone who doesn't control all of their infrastructure or works at a large organization.
Why would they be removed? If the CA correctly follows all of their procedures and approves a domain-validated cert, why punish them for approving what is a legitimate request?
If the CA is coerced into issuing a cert, however, I agree with you.
So isn't that a criticism of domain-validated certificates? This is a serious question. I haven't heard a compelling argument for how DNSSEC/DANE gives governments any more power than existing DNS delegation.
