4 ms·
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
by cdjk 12y ago
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.
- tptacek 12y agoThey can do that because of domain-validated certificates, and they can do that after the DNS is secured.
- cpach 12y agoAnd the CA that issues the cert will be flamed and possibly removed from Chrome/Firefox. (Edit: If they are caught.)
- cdjk 12y agoWhy 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.
- cpach 12y agoYou’re right. I misunderstood the scenario we were discussing.
- cdjk 12y agoSo 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.
- yuhong 12y agoDomain validated certificates do not require a new protocol however.
- acdha 12y agoI 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.
- revasm 12y agoPublic key pinning seems to be heading in a direction that relies on the current CA model. For example, see https://tools.ietf.org/html/draft-ietf-websec-key-pinning-20 https://tools.ietf.org/html/draft-ietf-websec-key-pinning-20, or https://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.certs https://code.google.com/p/chromium/codesearch#chromium/src/n... (Chrome's pinned certificate list -- which has a total of _9_ non-CA entries).
- acdha 12y agoCan 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: https://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#section-2.6 https://tools.ietf.org/html/draft-ietf-websec-key-pinning-20... > 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.