Google's Certificate Transparency proposal wants certificate authorities (CAs) to publicly log all of the certificates that they issue. It does not protect against NSA spying and MITM attacks. Website owners are then asked to monitor these logs to see if their clients were hacked. Everyone online still forced to trust the bad apple (the least trustworthy CA).
- Best case scenario: mis-issuance detected after damage has been done. The CA blames hackers.
DNSSEC suggests a complicated mechanism to essentially re-create many of the same problems with X509 and CAs in DNS itself, by providing a chain of trust to untrustworthy entities. Its intended goal is to secure DNS and thereby assure clients that when they ask for apple.com, they are actually visiting apple.com. This proposal does not protect against MITM attacks. It suffers from extreme and unnecessary complexity, a systemic fault that's antithetical to secure systems.
- 📄 DNSSEC Outages (Scroll down to "Miscellaneous" section)
- 📄 Against DNSSEC
In their words, Convergence:
...is a secure replacement for the Certificate Authority System. Rather than employing a traditionally hard-coded list of immutable CAs, Convergence allows you to configure a dynamic set of Notaries which use network perspective to validate your communication.
In our words: Convergence is similar to having a known_hosts ssh key file for your browser, and comparing it against your friend’s file. It's not a terrible idea, however:
- It is not very user friendly. Users are asked to manage a list of notaries. This list of notaries is stored locally on the computer, or even the browser. Managing this list is not feasible for most users.
- It's not clear how well it protects (or can protect) if some notaries haven't yet cached the latest SSL certificate for a particular website.
- It does not provide MITM protection on first-visit.
- Waiting for group consensus means all connections have higher latency (slower page loads).
- Both Convergence and Perspectives (see below) results in you sharing every website you visit with random third-parties. With DNSChain, if privacy is a concern, you can run your own server and only rely on it: it will provide both better performance and superior security.
Perspectives is very similar to Convergence and suffers from the same problems. It allows "no reply" from notaries, making it not useful in a MITM attack.
Both TACK and HPKP are mechanisms for doing public key pinning for individual websites.
These mechanisms are similar to how SSH uses a known_hosts file to store the fingerprints of public keys it encounters on a "Trust-On-First-Use" ("TOFU") basis.
The problem with these mechanisms is:
- They don't protect on first visit.
- They break websites when the public key needs to legitimately change.
- In the case of TACK, the TACK public key needs to change very frequently (at least every 30 days). This defeats the purpose of pinning, as a MITM does not need to wait long before they can present a fraudulent key that the user has no way to know is legitimate.
- These mechanisms assume that client software has its current time set properly, and they break when that's not true.
While DNSChain does use public key pinning, it doesn't have these problems because there is only one pin that is ever required: the pin to DNSChain itself, which is easily verified once only at setup.
Thin Clients are very important and we are working to define and integrate arbitrary thin client techniques into DNSChain.
So far most thin clients use Simplified Payment Verification (SPV) as their verification method. SPV may not work well in all situations, however:
- Apple's iOS does not allow you to download and run servers in the background that other apps can talk to. This is an issue for SPV, which needs to always remain synced with the network.
- SPV can result in a slower user experience on mobile devices. If the device has been off for a while, users would need to wait until the thin client syncs back up with the network before before accessing online resources.
Proof-of-Transition is a thin client technique that may work better on iOS.
It's important to remember that while thin clients are very important, blockchains are only as healthy as the number of full nodes there are, and full nodes can only reasonably be run on a server. DNSChain helps encourage the wider deployment of full nodes by making them accessible over a single protocol.
Useful resources on thin clients: