UPDATE April 21, 2017: Read the latest and most relevant blog post on DPKI versus CONIKS, CT, KT:
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 is 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 does not protect you if the MITM is sitting in front of the server you are visiting. Notaries would see exactly the same key that you see (the one that belongs to the MITM).
- It introduces high latency on first visit in order for group consensus to form.
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: