The bulk of my original request:

This acknowledges receipt of your November 23, 2014, Freedom of Information Act (FOIA) request to U.S. Immigration and Customs Enforcement (ICE), for a list of ALL internet domain names that ICE has participated in seizing up to the present day. While there are few documents with dozens domains, ICE press releases indicate that the number is well over a thousand. To be clear: also interested in domains that were part of join operations, such as that of Europol (http://www.infosecurity-magazine.com/news/700-domains-seized-by-ice-europol-and-hong-kong/). Your request was received in this office on November 25, 2014.

Due to the increasing number of FOIA requests received by this office, we may encounter some delay in processing your request. Per Section 5.5(a) of the DHSFOIA regulations, 6 C.F.R. Part 5, ICE processes FOIA requests according to their order of receipt. Although ICE’s goal is to respond within 20 business days of receipt of your request, the FOIA does permit a 10- day extension of this time period. As your request seeks numerous documents that will necessitate a thorough and wide-ranging search, ICE will invoke a 10-day extension for your request, as allowed by Title 5 U.S.C. § 552(a)(6)(B). If you care to narrow the scope of your request, please contact our office. We will make every effort to comply with your request in a timely manner.

The 30 day deadline passed, but between work and my volunteer work, it fell off my radar. Six months later, I sent an email asking for an update and got the following:

The program office is still conducting its search for your request. Thank you for your patience.

Three months later, I still haven’t gotten my fucking list. Like everything else in life, climbing to the top of someone else’s TODO list requires proving to them that you will be a PITA. So I paid $20 and filed a “new” request through MuckRock.com. That money buys me an email address used by professional muckraker and free advice if I run into more stonewalling.

Here’s hoping I don’t need to hold a fundraiser to pay a lawyer to send ICE nasty letters.

Two-factor authentication (2FA) has become very popular because stolen tokens cannot be used to authenticate the user at a later date. So if the password is leaked or easily guessed, the user is still safe.

However, I’ve noticed a serious UX deficiency common to time-based (TOTP) 2FA client applications such as Google Authenticator and Authy: they force users to spend a lot of time on useless tokens.  This has gone unnoticed by implementers because they do not experience the interaction in the way a typical user would.

Authentication servers actually accept late tokens, typically within one “time-step” ”“ which is about 30 seconds.  So the server won’t reject a token even if the user submits the token at the moment that it “expires” locally.  However, users are ignorant of the backend and the vast majority of them will assume that the token expires shortly after it disappears from their screen.

Users also have to type the token in before it disappears from the screen.  People of average intelligence can simply read the 6 or 7 digit code and reproduce it from memory.  However, roughly 50% of the population would be unable to store the token in short-term memory, so they would have to refer back to the application to re-read the token.

Crafting an interface for a 2FA application should thus take into account that users will not submit a token unless there is enough time for them to type it in and submit it before the token expires locally.  Some modeling and time trials (see Appendix A: Timing) suggest that it takes about 5 seconds to reliably type in a security token and about 10 seconds to comfortably type one in.

Since tokens are time-based, a user may get a token that has 30 seconds or 5 seconds remaining before it expires¹.  Since it takes ~5 seconds to type in the token it would appear that users are (on average) waiting for the next token to appear ~20% of the time.

A few seconds might not sound like much, but waiting is irritating.  Think about it: ~20% of time people spend using a 2-factor authentication app is time spent being irritated.  So what can we do? Show the upcoming token! You don’t even need to label it, just use an animation to replace the expired token with the upcoming token:

Screenshot of Authy, a popular 2-factor app with the standard 2-factor UI.

Mockup of change with upcoming token displayed below the current token.

I suggested this to the Authy team and I got a response that is sadly familiar to anyone doing security focused usability research:

May I ask why you would need to enter in the code so quickly and frequently? We don’t share the next security code until the prior has expired for security reasons. Having both up at the same time would take away from the security that is provided by the codes.

Translation: you are lazy and I’m going to point to a minor security issue to justify not making this change.

Well, it’s not quite that ignorant, I received a similar response other programmers and security researchers.  The problem is that these are smart people who can take in token in a single glance and know that the backend servers will accept it even if the client application has “expired”.  Expert users understand that a Zombie Token will still work while regular users will assume that such tokens are simply dead.

I say that the security issue is minor because taking advantage of the additional token being displayed on a phone’s screen would require an attacker that can view the phone’s screen and enter in the token in real time.  An adversary with the resources to carry out a dedicated attack and view the user can typically gain physical access to the computing device.  The only scenario in which showing the additional token would matter is if the attacker can see the user through a window or was able to plant a camera in the workplace but unable to access the computer directly.

However, it’s fairly trivial to accommodate this threat model while still eliminating Zombie Tokens.  The fix is pretty simple: five seconds before the current token expires, display an obfuscated preview of the upcoming token that the user can manually swipe in:

The upcoming token peaks in on the side 5 seconds before the current token expires.  Users can manually swipe it in and replace the current token.

If the user finishes typing in the current token and closes the app before it expires, the upcoming token won’t be displayed in its entirety and the attacker won’t gain access to an unused token.  If the user would have waited for a new token anyway, they can skip ahead and start typing immediately.  This additional interaction ensures that the two interfaces are equivalent in terms of security (see Appendix B: Threat Modeling for an in-depth explanation).

This fix isn’t quite as usable as simply displaying the next token as users have to figure out that they can swipe the new token into place.  If you are willing to relax the security requirements a bit, you could show the full upcoming token but limit its display to ten seconds before the current token expires.

Usability is security: the more usable a security measure is the more likely people are to use it.  Two factor authentication is a great way to beef up the security of traditional login systems.  Sadly, Zombie Tokens make the user experience irritating 20% of the time.  But we can eliminate Zombie Tokens without sacrificing security.  Authy may or may not take my advice, but I’ve done my part in trying to wipe out Zombie horde.

Appendix A: Timing

I arrived at the 5-10 second time through a combination of timing trials in which I entered in a 6 digit token and modeling user input using GOMS.

GOMS is a framework for calculating the efficiency of user interfaces: you build a model by inputting each task and the framework calculates the total time required to complete the task based on time and motion studies of actual users.  It quite literally calculates the time required type in text, move a hand to the mouse, click a button on a screen, etc, etc.  The model I used to calculate the 5 second lower bound looks like this:

Look at phone
Store 544438
Look at computer
Hands to keyboard
Type 544438
Hands to mouse
Point to submit button
Click submit button

The above task is estimated to take 5.0 seconds to complete.  It is consistent with a few time trials in which I entered in a 6 digit token. However, the 5 second time felt very rushed and both the above GOMS model and the time trials made a few assumptions:

• The token is 6 digits long.
• The text field for entering the token has the keyboard focus.
• The user can store the entire token in short term memory.
• The user does not attempt to verify the token’s correctness.

Lengthening the token to seven digits and adding additional mousing and verification tasks to the GOMS model boosts the estimated completion time to 9.4 seconds.  Correcting a typo within the GOMS model resulted in a estimated time of 11.1 seconds.  When balanced with the subjective observation that typing in a 6 digit token in under 5 seconds feels rushed, the average time to comfortably complete the task probably lies somewhere between 5-10 seconds.

Appendix B: Threat Modeling

Matching the security parameters of the existing system entails not leaking any tokens that wouldn’t be leaked by the existing UI under an equivalent attack scenario.  We’ll start by defining the threat model and examining what tokens the existing UI would leak.

To take advantage of the preview token, an attacker would need to be able to view a phone’s screen and submit the token in real time.  For the sake of argument, we will assume that the surveillance is limited to a camera that has been planted in the workplace or that the target user is visible through a window.

An attacker with this level of access could steal the current token and submit it before the legitimate user is able to. I simulated this attack by switching Firefox and Chrome into incognito mode, logging into web service and reaching the 2FA input screen in both browsers, and then submitting the same 2FA token in both browsers in rapid succession ((It would be fun to see what happens when the IP addresses differ but my SOCKS proxy failed me.  However, if an attacker can plant a camera in your workplace they can probably plant a WiFi AP.  The IP address checks are often based on geo-location anyway, so the attacker would probably be okay as long as they are using an IP within the same area.)).  I performed this test with GitHub, CloudFlare and Coinbase.  GitHub allowed the login whereas CloudFlare and Coinbase simply reloaded the page.  So for many of these systems, the attacker could enter in the current token and the user wouldn’t be alerted to the fact that their token was hijacked.

The traditional UI would also leak unused tokens.  The user wouldn’t necessarily lock their phone’s screen right after entering in a token on their computer.  Indeed, I would suspect that most users would get distracted with the task at hand and forget about the phone sitting on their desk, broadcasting fresh security tokens to any overhead camera or onlooker.

If a user is presented with a token that will only last for 5-10 seconds, they will probably just wait for the next token.  An attacker could submit the unexpired token while the user waits for a fresh one.  They would have to be quick, but the threat model assumes an attacker performing real-time surveillance.  I’m sure someone could whip up a login script to speed up the process while the target is on lunch break.

To review, the current UI would allow an attacker to steal:

1. the current token, although some systems might display a security warning;
2. any tokens that are displayed after the user has entered in the current token unless the user turns off the screen immediately after entering in the token;
3. any token that the user allows to expire while waiting for a new token.

Preventing a token from leaking under #3 requires preventing the upcoming token from being displayed unless we are positive that the user won’t use the current token.  So if the user is still typing in the current token <10 seconds before it expires, we cannot display the upcoming token.  Instead of simply displaying the upcoming token, we obfuscate it and require user interaction to display it in its entirety.

1. For some configurations, the Authy app displays a fresh token when the app opens but reduces the valid time to 20 seconds.  This is an improvement, but the user may not be ready to type in the token when they open the app. ↩

The dynamic nature of the web gives service providers the ability to target individual users with a backdoored version of their web client every time the site is loaded, an attack that Hushmail validated back in 2007.  Mailvelope and similar browser addons can move message decryption to iFrames or new windows and rely on the same-origin policy to restrict the reading of content from the service provider.  Unfortunately, as long as a service provider can spoof the UI, they can copy the plain text version of new messages and send an encrypted version to the recipient.

Mailvelope attempts to mitigate spoofing attacks through the use of security iconography, or “watermarks” as Mailvelope calls them.  Mailvelope randomly generates a security icon during installation which is incorporated into Mailvelope UI elements.  If the icon is different, users are not supposed to proceed, akin to site-authentication images used in some bank logins.  However, security icons cannot effectively mitigate a UI spoofing attack because security icons do not work.

Researchers have been testing the efficacy of security iconography for over a decade, and the results are dismal.  The most dramatic “experiment” was performed by Moxie Marlinspike in 2009.  Marlinspike removed encryption from connections using a malicious Tor exit node, which also removed the browser encryption icons.  Despite drawing his sample from a population with above average technical acumen and paranoia, he achieved a 100% “success” rate; meaning that every user who visited a login page logged into to their account. Marlinspike collected over 400 logins and 16 credit card numbers in 24 hours.

Of course, the encryption icons for browsers are smaller and somewhat different from what Mailvelope uses.  The closest thing to Mailvelope’s “watermark” are personalized site authentication images displayed by many banks during the login process.  In The Emperor’s New Security Indicators, researchers asked users to login to their bank and surreptitiously removed site authentication images, 22/25 of the participants sent their login information, a 92% failure rate.  Some will question the validity of this statistic due to the small sample size, however, the results are in-line with a decade of research and the lab setting boosts user awareness.

Increasing the size and prominence of the security indicator will not decrease the failure rate to acceptable levels.  One study devoted the entire browser skin to conveying encryption information and saw only modest improvements to user behavior.  It shows that most users don’t understand the purpose of the information and that the software must determine if something is safe.

Screenshots of the browser skins used in one research study. A was displayed for an EV SSL certificate, B for traditional SSL certificates, and C for unencrypted connections.

The fundamental issue is that human cognition has limits: we cannot process unlimited amounts of information.  The assumptions made by the security model underpinning security iconography ignores a decade of behavioral studies and runs counter to 50 years of cognitive psychological research.  Just try to accurately count the number of times a player passes a basketball in the following video:

The 50% failure rate for the above video is artificially high, as the laboratory environment heightens user awareness.  The task is also very different from that of checking a security icon.  The tricks employed by pickpockets are a better real-world analogy for spoofing a security icon.  Watch as Apollo Robbins carefully manages the mark’s “cognitive spotlight” using misdirection to control the information that the mark is consciously aware of:

At 3:10 you can see how Robin applies pressure to the wrist near the watch clasp and then draws the mark’s attention elsewhere.  The initial stimulus is registered, deemed non-relevant, and then Apollo uses misdirection to remove the stimulus from the cognitive spotlight.  The stimulus is still present, but the nervous system and the brain must filter the signal down to relevant stimulus.

A user composing messages is in an even more precarious situation, as habituation conditions us to preemptively ignore information.  Unless something is integral to the task itself, we will filter it from your cognition.  Even if the user is asked to confirm that the icon is valid, they will habituate the task and complete it automatically¹.  While a pickpocket must create new stimulus to control the cognitive spotlight, habituation will suppress the stimulus from even reaching the cognitive spotlight.

I don’t want to get too deep into the neurological details, but the inevitability of filtering stimulus that is irrelevant to the task workflow is fairly obvious if you think about the amount of information your body processes: temperature and pressure from your skin, taste and smell from your nose and tongue, your complete field of vision, and all of the sounds present in your local environment. There are even filters for information that has been processed abstractly, which is why you can pick up on someone saying your name at a cocktail party but ignore ambient conversations after you start talking with your friend. Without these filters, we would be overwhelmed with irrelevant information.

The inability to effectively mitigate user interface spoofing attacks cripples the usability of these bolted-on E2E interfaces. They must lift the new message and reply UI elements out of the browser chrome. They must also create a distinct contact manager to handle public keys. The only thing left is detecting encrypted messages, which Mailvelope decrypts and displays in an iFrame. I’m not sure that even this is safe, since the service provider could display a “Reply Securely” button over the decrypted message.

A website is a very hostile environment to be operating in. The URL bar is a remote function call interface which retrieves a Turing complete programming environment in the form of a website.  The service provider can target individual users, deliver new exploits at any time, and has total control over the messaging system.  I’m just not sure that we should be relying on the same-origin security policy of browsers to protect our encrypted communications.

On the web, the best we can do is ensure a secure connection and valid DNS information; trust in the service provider should be assumed.  With traditional software systems, we can use reproducible build systems to distribute trust and security audits to increase the cost of backdooring software. But without a clear separation between the messaging system and the software used to retrieve messages, we cannot build usable messaging systems that deploy end-to-end encryption.  Any user interface that is secure against UI spoofing will only be a step above manually copying and pasting in the ciphertext.

Mailvelope and service provider based end-to-end encryption is still potentially useful. They raise the cost of an attack and force service providers to participate in serving backdoored versions of their sites and may add additional legal hurdles.  It *may* be possible to bolt a usable PGP client onto website in a that can defend against malicious service providers.

But one of the many lessons Snowden has taught us is that the only thing worse than bad security is the illusion of good security. Such solutions should not be used by high-risk groups until they can prove that they can reliably defend against malicious service providers.  Until then, vendors of such software have a moral duty to try and prevent users from high risk groups from using their software.

Update: Some comments on my blog assert that the security situation is very similar to what can be performed through basic software updates.  I’m aware of this, an I have a few thoughts.

First of all, journalists and human rights workers really should be using TAILS, which is at least publicly auditable and in a position to refuse to comply with US court orders.  Furthermore, I believe that we should treat development of software for these users as if lives are on the line.  In that regard, it is at least possible to make attacks against the operating system and applications more expensive, which isn’t true of the attacks against E2E web crypto.

For example, we can create an operating system that uses reproducible builds for everything.  We can also define a software subset that is required for journalists or human rights workers (an email client, a chat client, a basic document editor, and a web browser) and use security audits, sandboxing, and (eventually) formal verification to drastically increase the cost of an attack.

I’m also concerned about projects like okTurtles, which want to make it easy to build a Mailvelope-like E2E client for any software platform, such Facebook and Twitter.  okTurtles claims to be “MITM-proof” and mentions journalists and human rights workers in its marketing.  I’m afraid that someone will take them at their word build an okTurtles front end for vKontakt or Weibo.  I hate the NSA and the US has a shitty human right record, but this would make it easy for Russia and China to precisely target users.

1. Browser add-ons cannot switch to blocking the user’s task flow, as they are dependent upon the service provider delivering accurate hooks into their interface.  For example, no one would notice a silent forward from mail.google.com to www.mail.google.com. ↩

Introduction

okTurtles and DNSChain make fantastic claims about some very vanilla software, such as being impervious to MITM attacks, fixing HTTPS, and that their third party trust system “is at least as good as lightweight [clients].”  They believe that a transparent HTTPS proxy, Unlock.us, is immune to DPI and thus “short of cutting entire countries off the internet, DNSChain/Unblock.us will be able to get through.”

Blockchain technology has the potential to make a significant impact on the usability of encryption and anonymity networks.  Unfortunately, okTurtles and DNSChain consistently misapplies this technology.  okTurtles is a end-to-end encryption client that is vulnerable to MITM attacks and advertises an impossibly good user experience.  DNSChain doesn’t fix HTTPS generally and they are pushing a 3rd party trust system that needlessly breaks the key MITM protection offered by blockchains.  Unblock.us isn’t immune to traffic analysis and isn’t safe for use in countries that block commercial VPNs and proxies.

I’m writing this because misleading users about security and anonymity software can have dangerous consequences.  Tor’s lead developer once relayed an anecdote about an Iranian Tor user who taught fellow political dissidents how to use censorship circumvention software.  At some point, the user realized that the people whom he had trained to use Tor were still around and everyone using something else was in prison.  This is the reality for security-related software projects and their marketing claims should be held to a very high standard.

okTurtles

Marketing Hype

• “MITM-proof communication through almost any website, with zero intervention needed from the site operators.”
• “… it will stop all of the publicly known methods by which the NSA can read your messages on these sites via a MITM attack.¹”
• “… true end-to-end encryption and authentication between you and the person you’re communicating with that does not fall prey to … interception, redirection, and/or tampering-with of the communication in question.”
• “… making this surveillance simply irrelevant.”

The Reality

• okTurtles is an end-to-end (E2E) encryption client for online platforms, such as Facebook and Twitter.
• It is inherently vulnerable to MITM attacks by service providers.
• It cannot effectively mitigate UI spoofing attacks without crippling usability.

okTurtles advertises an impossibly good user experience that is not “MITM-proof.”  Trying to bolt an E2E client onto a website opens okTurtles up to a range of attacks that are not true of other messaging systems: UI spoofing.  A service provider can spoof okTurtles interface, tricking the user to enter text into a text field they can read, save a copy of the plaintext, and forward an encrypted version to the recipient.  With closed loop systems like Facebook, they can detect if both sides use okTurtles and spoof message decryption and verification on both ends.

Websites are Turing complete programs and logging into a web platform allows the service provider to serve a malicous version of their web client.  The service provider can spoof the okTurtles interface, the identity of the user, contextual menus, and even manipulate copy and paste commands.  The only way to mitigate these attacks is to move the contact list, the text entry field, the new message button, and the reply button outside of the website.  This negates nearly all of the usability benefits promised by okTurtles.

Every UI component could be spoofed by the service provider.  They can save a plaintext copy of the input and send an encrypted version to the intended recipient. This mockup also makes it appear as if okTurtles is fetching cryptographic identities automatically. A service provider could show one identity to the user while exposing an identity they control to okTurtles.

Messaging software itself can be backdoored, but we can at least turn to deterministic compilation and security audits to increase the cost of such an attack (and few claim to be “MITM-proof”). Not only is this not possible on web platforms, it’s trivial for service providers to precisely target victims, detect if the user has okTurtles installed, and deliver a new payload every time a user logs in.  Unlike email, Facebook and other service providers have total control of the messaging system.  I’m also wary of relying on the browser’s same-origin-security policy to protect our private communications and encryption keys.  The browser is a very hostile environment to try and build secure software in and trust in the service provider should be assumed.

Browser-based E2E encryption is still potentially useful.  It raises the cost of an attack, it forces service providers to actively participate in serving backdoored versions of their sites, and it may add additional legal hurdles.  Using blockchains to specify identities is more usable than selecting public keys and is resistant to a specific type of MITM attack.  If okTurtles only claimed to provide protection against dragnet surveillance or modest improvements to usability, I would have no issue with the software.   But okTurtles advertises it for use by human rights workers and journalists and claims that “… it will stop all of the publicly known methods by which the NSA can read your messages on these sites via a MITM attack.”

Furthermore, okTurtles wants to make it easy for others to write plugins to support other web platforms.  Journalists and human rights workers might be comfortable trusting TAILS and Thunderbird developers to resist governmental pressure to deliver an update with a backdoor.  You might even be willing to trust Google or Facebook not spoof the UI, but I fear that someone will take their “MITM-proof” claims seriously and port the software for use on Weibo or vKontakte.

If okTurtles sold itself as a more usable E2E client, as Mailvelope does, I would not have a problem with the software.  But okTurtles is advertising an impossibly good user experience that is trivially vulnerable to UI spoofing.  A browser add-on could be built that is resistant to UI spoofing, but it cannot integrate with the web client’s interface directly.  The result will probably be a few notches above copying and pasting the ciphertext manually and it certainly won’t be as usable as dedicated messaging software.  okTurtles might be a step forward, but it will not “make surveillance simply irrelevant” and their UI mockups and security claims are dishonest.

DNSChain

Marketing Hype

• “HTTPS is broken. DNSChain fixes it.”
• “MITM-proof’ed Internet connections.”
• “DNSChain now has a 3-pronged security model that is at least as good as [lightweight clients]²”

The Reality

• DNSChain is middleware, primarily a DNS server and a REST API that retrieves information from a blockchain.
• DNSChain does nothing to fix HTTPS for 99.99%+ of domains.
• They are pushing 3rd party trust solution that breaks the MITM protections provided by blockchains.
• Their security is inferior to lightweight clients.

DNSChain’s derives its security benefits from Namecoin and similar cryptocurrencies.  Cryptocurrencies can prevent MITM attacks against faulty DNS and TLS information for specific top-level domains.  DNSChain does nothing to protect 99% of top level domains (such as .com or .net) and it does not fix HTTPS generally.

Indeed, DNSChain doesn’t have much to do with the protections it derives from using blockchains, such as Namecoin.  The following feature matrix is copied from DNSChain’s Github repo, but it specifies which component provides the claimed feature.

DNSChain was initially a pure client/server model which they advertised as “MITM-proof.”  After receiving pushback on this, they added two features: checking multiple DNSChain servers and public key pinning (“Proof-of-Transition”).  But this is nothing new: checking multiple peers and storing cryptographic information from the first connection are as old a cryptography itself.  Moxie Marlinspike was a pioneer in building systems similar to what DNSChain is proposing for HTTPS, such as Convergence and Tack.  However, neither of Marlinspike’s projects claim to be “MITM-proof” and DNSChain breaks MITM protections offered by blockchain technology.

Slepak (DNSchain’s lead developer) claims that DNSChain’s client/server model is “at least as good as” lightweight resolvers.  This is simply not true and demonstrates a basic ignorance of lightweight technology, which can preserve the full MITM protections offered by the Nakamoto blockchain⁵.

Update DNSChain’s lead author followed up with a claim that, “If I run DNSChain at home or on my server, it’s equivalent to the security a full node would provide me with, and that’s superior to lightweight clients.”⁶

This “user running a server” configuration is a fictitious use case.  As I explained in my first DNSChain blog post, this is equivalent to claiming everyone will run their own email server. Thus, for 99% of users, DNSChain is a third party trust solution.  Slepak basically agreed with this analysis but claimed that everyone would buy a PlugPC that would function as their server.  In my second DNSChain blogpost I explained why this would never scale and how it locks us into trusting the PlugPC manufacturer.

The primary Namecoin lightweight resolver (which I will call a UNO resolver) has storage requirements that are less than that of a Bitcoin SPV client while offering security more akin to a Bitcoin UTXO client.  Name-only resolvers do not need to worry about double spends, so they only need to store a few dozen megabytes of block headers. Because name-only resolvers only need to store headers for current names, their storage requirements do not increase over time.  Furthermore, special data structures can be used to validate responses from full nodes, so there is no need to contact multiple servers.

An attacker with 50% of the network hashing power could trick a UNO resolver into accepting an old (but still valid) DNS record for 2 hours every few weeks.  I don’t know how much it costs to attack a DNSChain server, but it is certainly less than a 51% attack.  And for the 1% of users that can administer their own Namecoin full node, their UNO resolver could be configured to connect to their full node client.  No matter how you slice it, DNSChain’s third party trust system isn’t as secure as a UNO resolver.

Slepak is pushing this system because he believes that is more practical alternative to lightweight resolvers.  If you are willing to accept third party trust, threshold DNSSEC makes a similar compromise for blockchain based TLDs but offers a sane path to backwards compatibility.  However, lightweight resolvers are more usable than a DNSChain client because they do not require any configuration.  In terms of storage requirements and network performance, the differences between the two solutions are negligible even on mobile devices.

Slepak asserts that lightweight resolvers won’t work on iOS devices because iOS devices cannot share data between apps.  Downloading headers only amounts to about 220 KiB per day and they can be fetched preemptively or even pushed to the device.  Even if the lightweight resolver has to fetch some headers, it doesn’t have to query multiple servers, like a DNSChain client would.

When it comes to storage requirements, even the prospect of supporting multiple blockchains isn’t a big deal.  I can imagine a future where there are 5 relevant blockchain identity providers and maybe 3 blockchain based TLDs worth supporting.  Over the past 7 years, the minimum iOS  storage capacity has quadrupled from 4GB to 16GB.  Assuming linear increases in storage capacity over another 7 years, an app supporting name resolution for 5 different blockchains will take up <1% of an iOS device’s storage capacity.

Slepak also tries to make hay of the fact that lightweight resolvers are still a ways off from being complete, but so is DNSChain.  For Namecoin and Bitcoin, the necessary core changes are probably less than a year away.  Shoring up DNSChain’s third party trust system and building out all of the infrastructure needed to support it leeches funding and developers from solutions that offer something better than the status quo.  After all, if a blockchain identity solution cannot offer something better than third party trust, why would it succeed where Microsoft, Google, and other commercial entities have failed?

If DNSChain simply sold itself as middleware with a trusted server option that can support multiple blockchains, I wouldn’t have a problem with it.  But DNSChain keeps pushing a security model that breaks the MITM protections offered by the Nakamoto blockchain and unnecessarily ties itself to third party trust. Lightweight resolvers are more secure and practical even on mobile devices.  Finally, the DNSChain team has a track record for making deceptive claims, such as “fixing HTTPS” when they impact less than 1% of domains or being “MITM-proof” despite being a third party trust solution for 99% of users.

Unblock.us

Marketing Hype

• “DNSChain’s censorship circumvention is in many ways superior to Tor’s!”
• “…[Unblock.us is] indistinguishable from TLS and immune to DPI.”
• “Short of cutting entire countries off the internet, DNSChain/Unblock.us will be able to get through.”

The Reality

• Unblock.us is a HTTP proxy that is only used if a website is blocked.
• A censor can detect and block Unblock.us proxies without shutting off the entire internet.
• Circumventing censorship is trivial, scaling censorship circumvention is really hard.
• Unblock.us does not materially advance circumvention technology.

The official Unblock.us project is actually fairly responsible in the claims that they make; the above quotes are pulled from DNSChain’s Github repository and comments made by DNSChain’s lead developer.  However, statements about it being “superior to Tor” and being immune to DPI aren’t just misleading, they are dangerous.

It is trivial to detect and block Unblock.us. Their routing (unencrypted SNI headers) currently leaves the domain name visible, but they have proposed a fix which obfuscates the domain name.  The technical description of the fix makes it sounds as if the obfuscated domain could be detected using pattern matching. Even if we assume that they code specific unblocked domains to stand in for blocked domains (thus avoiding pattern matching) the unblocked domain name wouldn’t normally resolve to the proxy.  Even if they make a system in which the censor cannot be absolutely sure that it is a proxy, they can simply throttle the connection and make it unusable.  We could play a few more rounds of this cat-and-mouse game, but the point is that Unblock.us is not immune to traffic analysis.

Slepak claims that using HTTPS makes Unblock.us indistinguishable from other traffic.  However, Tor also tries to hide its traffic as vanilla HTTPS, but they do not claim that their protocol is indistinguishable from HTTPS traffic. This is what Jacob Appelbaum has to say about such claims,

One really important point here is that we are extremely clear about the fact that Tor is not a stenographic transport….  We don’t make that claim because people who make that claim are full of shit.

There are hundreds of researchers working on circumvention technologies.  Searching for “Tor” on Google scholar pulls up over 3,000 research papers. This is also a major industry: one major VPN service provider has 4 million in annual revenue and the DoD would love to have a stenographic transport for their military and covert operations.  In the twelve months that the project has been around, they haven’t managed to even perform a literature review, let alone invent a revolutionary new technology.

One of their selling points is that unlike commercial solutions, Unblock.us is designed as a friend-to-friend system and censors cannot just built a list of IP addresses.  But blocking of commercial VPNs and proxies tends to occur during political turmoil or in countries where there are no commercial interests that require access to a VPN.  It probably isn’t safe to be using a proxy in such an environment anyway, but using Unblock.us is especially dangerous because (unlike Tor and commercial options) it doesn’t mix traffic from a large number of users and thus doesn’t provide any plausible deniability.

Even where it is safe to use, Unblock.us won’t impact passive DNS censorship because it will not scale.  The deployment plan is identical to that of DNSChain; how many people do you know that are qualified to securely run a proxy server and willing to do it for free?  You can find an unmetered VPN for less than $5/month, which is cheaper than a VPS.  If someone can afford internet access, they can afford a VPN … which is easier and cheaper than paying someone to run a proxy server for you.

Unblock.us is an okay solution if you have the technical skills to operate such a proxy.  However, they haven’t discovered anything revolutionary, Unblock.us’s only advantage is its relative obscurity.  Since Unblock.us doesn’t provide plausible deniability, it isn’t safe for use in countries that actively block commercial proxies and VPNs.  Their only realistic use case is restricted to users who have a friend that is already paying for a VPS and has the time to administer a server for free.

Conclusion

I didn’t want to write this blogpost, even thinking about it makes me queasy.  I was sincerely hoping that Slepak would read my analysis and back-off from his claims so that I could delete the post.  A few weeks ago, I even offered to write Slepak a letter of recommendation to the Shuttleworth Foundation if he would fix his marketing.  After all, they funded Moxie Marlinspike to develop third party trust systems and E2E libraries. WhatsApp has adopted Marlinspike’s Signal library to provide E2E encryption for their users, but they could subvert it in a fashion similar to how websites can subvert okTurtles.

But from “MITM-proof” only applying to 1% of DNSChain users  to “fixing HTTPS” for 1% of domains to claiming that Unblock.us traffic is immune from DPI … they do not care that the plain reading of their marketing doesn’t reflect the reality of their software.  As Jacob Appelbaum said of Ultrasurf’s claim that it was indistinguishable from normal web traffic,

… it is super dangerous to make that claim and we would prefer to be very conservative so that when people use the system we know what they think they’re getting, honestly and truly.  That is absolutely the only way we think we will be able to ethically do this kind of thing. So it’s really important if you build or work on these systems to understand that it is way better to over deliver and under promise.  Because when you make a mistake or when something goes wrong, real people’s lives are really on on the line and we don’t want to mislead them.

There are other projects that are more responsible with their claims and also more advanced, such as Mailvelope, NMControl, and Tor.  Instead of engaging with these communities, DNSChain and company are busy reinventing the wheel, poorly.

The Namecoin team would welcome code contributions to NMControl for a more advanced third-party trust system.  It just happens to be a lower priority for us, as lightweight resolvers are generally a better solution.  We want to support multiple blockchains, NMControl’s backend is pluggable and we are planning on changing NMControl’s name to be more generic.  We would also love to see a NMControl plugin for the OpenName standard.  As long as the security parameters are accurately conveyed, we would happily support these use cases.

Myself and others have spent a considerable amount of time trying to engage with Slepak. But I have a real job and we should be focusing on Namecoin core, NMControl, and related development efforts; as such, I do not intend to spend additional effort addressing the current marketing and technical issues surrounding okTurtles, DNSChain, or Unblock.us.

If you want to contribute to advanced censorship-resistant technology, check out Namecoin core, NMControl, and other projects listed on the Namecoin GitHub repo.

1. The original version of this article outlined an attack in which the service provider performed a MITM attack against the initial identity handshake.  This can be fixed with out-of-band communication, but they failed to mention this and their documentation contains an image of a Twitter profile with link to a blockchain identity.  I removed this attack as the UI spoofing attack is more severe and easier to explain.  However, they do not prevent against all known MITM attacks and their “MITM-proof” marketing could dupe a user into thinking they don’t need to defend against this MITM attack. ↩

2. The exact quote used the phrase “thin clients” but it doesn’t make sense in the context of the conversation and Selpak helpfully clarified in a followup conversation on IRC that “thin clients is used as a synonym for light clients.” ↩

3. Their claim is that since their distribution model (“one DNSChain server per group of friends”) is a “flat” topology, there is no DNS server to DDoS. This almost makes sense if you believe that every friend group has someone willing and qualified to run a DNSChain server securely, which is about as realistic as every friend group having a friend who runs an email server for them. However, the current ISP based DNS system is very similar and we don’t see DDoS attacks against local DNS resolvers; root zone servers and nameservers are the only viable targets.  Blockchains are the equivalent of the root zone server and can store DNS information within the blockchain, removing the need for a nameserver.  However a DDoS attack against a cryptocurrency would also break DNSChain. ↩

4. DNSChain claims that “The wonderful thing about blockchains is that they have no conception of revocation because they do not need one. Instead, the most recent value for any particular key in a blockchain is the most accurate and up-to-date value.” This is based on a misunderstanding of how revocation and blockchains work. While it is possible to revoke a TLS certificate with a blockchain key, it is not possible to revoke the blockchain key. This has been pointed out to us as a security drawback by two high-profile security experts. While we intend to improve in this area (and have plans for doing so), it is incorrect to imply that the revocation problem is solved. ↩

5. In a response to this post, Slepak rightfully pointed out that lightweight resolvers described in the linked article are not equivalent to the full node installations, which was an oversight.  There are lightweight resolvers (FN-UTXO) that offer protection just shy of a full node installation and experimental implementations required around a couple hundred megabytes.  Since we are only interested in current domains, the installation size of a FN-UTXO is fairly stable, it would grow in proportion the popularity of the TLD (which can scale to the size of .info or .biz relatively easily).  But in the original version of this post I started talking about FN-UTXO resolver and then immediately switched to talking about a UNO lightweight resolver, which was confusing. But, as explained in the updated version, the UNO lightweight resolver is still more secure than DNSChain’s security model.

   Furthermore, Slepak’s response proves that he doesn’t understand Namecoin’s lightweight resolvers. He quoted from an O’Reilly book on Bitcoin SPV clients, stating that they had to query multiple servers, akin to DNSChain.  As explained in the article I linked to originally, Namecoin’s primary lightweight resolvers (UNO resolvers) do not need to contact multiple servers.  Compared to Bitcoin SPV clients, UNO resolvers do not require as much storage and offer much better security. ↩

6. The security model he was referring to in the original “at least as good as” quote does not specify running your own server, it only suggested that one, “Use a DNSChain server that you have reason to trust…”. ↩

Update

This article was meant as an overview of DNSChain, but it had a lot of drama.  I’ve written a more-up-to-date technical overview of okTurtles, DNSChain, and Unblock.us. While the security model for DNSChain has improved, they are still misrepresenting the security parameters of their software.

Originally, DNSChain was a pure client/server solution, every client would connect to a server with a full node Namecoin install with DNSChain acting as the middleware and DNS server.  Slepak (DNSChain’s lead developer) claimed that DNSChain did not require third party trust because everyone would have “friends” who would run servers on behalf of the user (which he called “second party trust”).  Since 99% of the population would rely on someone else to run a server for them, this effectively broke the MITM protection offered by Namecoin, despite DNChain’s claim of being “MITM-proof.”

The Namecoin development team pointed out that this is unnecessary, as lightweight resolvers only require a few megabytes to operate locally.  Later I debunked his claims regarding 3rd party trust and knocked the original scheme down as insecure and infeasible.

Slepak then started pushing the notion that everyone would have home router as their trusted server.  I knocked this updated scheme down as infeasible (10% of American’s don’t even have a home internet connection) and showed that it would loop router manufacturers into the trust base.  And, again, it is totally unnecessary given that lightweight resolvers require less than 100 megabytes of local storage.

DNSChain then added two features: checking multiple DNSChain servers and public key pinning¹ (Proof-of-Transition).  Slepak now claims that this is “at least as good as” lightweight resolvers.  This is simply not true and demonstrates a basic ignorance of lightweight technology.

Astute readers will have noticed that DNSChain has simply reinvented all of the hacks used to improve third party trust.  Marlin Moxiespike was a pioneer in building systems similar to what DNSChain is proposing, such as Convergence and Tack.  However, neither of Moxiespike’s projects claim to be “MITM-proof” and it’s difficult to understand how DNSChain can claim security benefits beyond what is already offered by these projects.

I have every reason to try and suck up to Slepak, he might have funding some funding soon and he dangled the possibility of funding Namecoin projects directly. But honest and accurate marketing of the security parameters of their software is a prerequisite for any endorsement.  So I dug into okTurtles, Unblock.us.org (related projects) and checked out their website.

I pointed security flaws with okTurtles and problems with their marketing over email, such as the claim that DNSChain “fixes” HTTPS.  Slepak deflected this latter criticism and said that the fully qualified claim was excessive.  Slepak regularly uses this “it’s just marketing” excuse and generally doesn’t care that the plain reading of their claims don’t match up to reality.  I agree with what Tor developer Jacob Appelbaum said of a similarly misleading claims made by Ultrasurf,

… but it is super dangerous to make that claim and we would prefer to be very conservative so that when people use the system we know what they think they’re getting, honestly and truly.  That is absolutely the only way we think we will be able to ethically do this kind of thing and so it’s really important if you build or work on these systems to understand it is way better to over deliver and under promise.  Because when you make a mistake or when something goes wrong, real people’s lives are really on on the line and we don’t want to mislead them.

Even if we ignore all of the security problems and their problematic behavior, DNSChain is a waste of developer time and funding.  DNSChain itself is entirely duplicative of NMControl and should have just been written as a plugin for NMControl.  We also need funding for lightweight clients and Namecoin core, which is the software from which DNSChain derives all of its security claims from.

Namecoin core needs at least one full-time engineer to make the fundamental changes needed for it to go mainstream, such as increasing domain pricing and setting renewal periods to fixed time intervals.  We also need developers for the lightweight client and revamping the build system, this amounts to at least $150,000 in funding.  Our estimated need for NMControl (which DNSChain essentially duplicates) is 1/10 of what we need for core engineering.

DNSChain has a track record for poor security engineering, misleading marketing, it duplicates NMControl’s functionality.

1. In that as long as the server doesn’t lie the first time around, future lookups are safe. ↩

I’ve been thinking a lot about transport-dependent DNS settings (BIND, http, tor, and i2p) and the architecture the original Domain Name System and applied encryption. After long talks with Ryan-C and Mark of EasyDNS, I believe we need to recast Namecoin’s purpose as a decentralized trusted base which offers secure delegation, not as a generic key->value datastore.

A Trusted Base

The real innovation offered by the blockchain is the ability to have trusted transactions between untrusted parties. Public-key cryptography offered a similar breakthrough 40 years ago: trusted communication across untrusted channels. However, public-key cryptography comes with a severe amount of overhead and it is NOT used to encrypt the bulk of the communications but only the initial symmetric key exchange.

A Terrible Datastore

By extension, the additional overhead required to store data on the blockchain makes them slow and costly generic key->value data stores. They also do not offer any protections for their users, whether it is Tahoe LAFS over I2P, Freenet, or a PHP upload script on a Tor hidden service, Namecoin is simply a lousy choice for publishing material that runs afoul of the powers that be.

Domain Name System

Even ignoring the generic data storage use case, Namecoin isn’t very good at storing DNS entries either. As antiquated as the domain name system is, John Postel put together an architecture that has scaled from a few dozen machines to a few billion over the past 30 years. The key to this scaling is delegation, Verisign and other organizations that manage root zone files for TLDs do not store full blown DNS entries, they store links. The root zone files for .com is 9.5 gigs of the following:

NS2.EXERTIVE AAAA 2001:db8:85a3:8d3:1319:8a2e:370:7348
NS3.EXERTIVE A 68.180.194.243
NS3.EXERTIVE AAAA 2001:db8:85a3:8d3:1319:8a2e:370:7348
NS4.EXERTIVE A 68.180.194.243
NS4.EXERTIVE AAAA 2001:db8:85a3:8d3:1319:8a2e:370:7348
NS1.CYBERTX A 98.136.63.35
NS2.CYBERTX A 178.65.210.178

Public Key Infrastructure

However, what of the case of id/? Again, storing the actual public keys in the blockchain turns out to be a terrible idea. A proper keyserver must be able to store an arbitrary amount of material. Each id/ would come with a signing key and an encryption key, both of which can be an arbitrary length. But we must also store child keys, email addresses, endorsements from key holders, an image of the owner, etc, etc.

Great for Secure Delegation

In every cryptographic trust system we find the use of a master signing key (a key signing key, a root certificate, etc, etc) which is used to sign child keys. The best practices for one of the oldest public key systems, PGP, is identical to that of all the others: create a master key which is stored on an air-gapped machine that then signs one’s everyday keys. Others only need to trust the master key to validate which child keys are still valid.

This is known a well-known design pattern called secure delegation and it fits perfectly with the capabilities of Namecoin. Every single proposal for Namecoin comes down to three elements: a human meaningful name (URN), a link to an authorized server (URL), and a public-key hash.

Other than convenience items for short DNS entries, such lists for translate/DNAME, alias/CNAME, and import statements, d/ records should be restricted to an ns and tls arrays. The same goes for id/: public key hashes, website and email links, and (for convenience) short ECC public keys.

Why Does This Matter?

While Namecoin is a key -> value datastore, this ignores the reality that blockchains are databases that accommodate small pieces of information that change on the order of minutes to hours. The strengths Namecoin and our datastore is most efficiently communicated as a decentralized trusted base. This mental model better reflects Namecoin’s strengths and weaknesses, leading to better architectural choices both internally and externally.

Architectural Choices

I came to this conclusion while trying to work out additions to the current d/ record specification for HTTP transport (aka frame resolution, jsDNS, Speech.is, etc). I won’t get lost in the details of that process here but it was clear that the right solution was to use a nameserver.

But this became a recurring theme:

1. How should we handle a server that supports transport over DNS, HTTP, Tor, and I2P? A transport neutral specification would help but there would always be transport specific options that would not only complicate matters but also bloat the record.  It’s better to just point to a transport specific nameserver.
2. How should a registrar handle their customers DNS entries? Nameservers!
3. How should /id handle large keys? Keyservers!
4. …

Brain Dead Ideas

Some crank came onto the forum recently to announce a new service: NamecoinFiles.org. This idiot thinks that the world needs a service which specializes in uploading files the Namecoin blockchain. We’ve also had an idiot come onto IRC who wanted to upload an archive of The Pirate Bay to the Namecoin blockchain.

Now, there is no way the blockchain would ever become a real platform for distributing such materials. We’ve checked with lawyers, and as long as the price is high enough we won’t get into any trouble either. Lightweight resolvers can also shed such material, so their impact is limited to being one-off pranks.

However, we don’t need these headaches. I think that as long as we brand Namecoin as a generic, censorship resistant key->value datastore, these sorts of idiots will keep popping up.

Ramifications

Branding

We should rebrand the website and altering our internal and external communications to emphasize the trusted base model is a fairly logical next step.

Simplification of Specifications

As noted above, I believe that records stored on the block chain should be trimmed to a URN, URL, and public-key hashes and a minimum number of convenience fields. Each transport is free to have arbitrarily complex records which are retrieved each namespaces equivalent of a nameserver.

Changes to Record Size

Trimming records to a URN, URL, and hash drastically reduces the size required for each record. There was already an accidental 512 byte limit on record sizes, but we’ve nixed plans to increase the size and keep it at 512 bytes.

Take a hypothetical domain name record consisting of an array of nameservers accessible over plain-old-DNS (PODS), Tor, and I2P plus two hashes of the public keys:

"ns": [
  "ns1.example.com",
  "ns2.example.com",
  "suw74isz7wqzpmgu.onion",
  "7e3e1add61049555.onion",
  "ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p",
  "udhdrtrcetjm5sxzskjyr5ztpeszydbh4dpl3pl4utgqqw2v4jna.b32.i2p"
],

"tls": {
  "sha2": "a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447",
  "sha3": "9103cd7811eb11c25788b5ce87b55ec10ee87e86d0bf4d383da139015d39a924"
}

The above clocks in at <400 bytes. Domains that need more can use an import statement.

Update

After I posted this, DNSChain adopted distributed trust as well, in that it will contact multiple DNSChain servers.  If you reject DNSChain’s claim that users will run their own trusted server, the security of a DNSSEC validating local resolver approaches DNSChain while maintaining backwards compatibility with existing infrastructure. Remember: lightweight resolvers have equivalent usability and better security than DNSChain.  The DNSSEC compromise gives up some security in exchange for a realistic path to universal resolution.  When it comes to domain name resolution, DNSChain compromises the blockchain security model without gains in usability¹.

Crank Like Behavior

Despite Greg’s claims, DNSChain is a trusted server solution: the general populace will either trust “friends” or their router manufacturer. We will get to a better trusted model in a moment, but it’s important to note that DNSChain is sold as a solution which eliminates MITM attacks and does not rely on third party trust, both of these assertions are clearly false.

Their falsehoods are compounded by the fact that DNSChain’s authors go out of their way to avoid admitting that they rely third party trust, using euphemisms like “friends” or “second party trust”. I spent a lot of time trying to explain this to Greg, DNSChain’s lead developer. Eventually, he switched from claiming “friends” would run servers to everyone relying on remotely connecting to a home server (maybe a router or a plug-pc). After I knocked that down as infeasible, DNSChain’s author didn’t address those weak points but changed the conversation, stating that it’s still “early days” and then making additional outlandish claims such as, “DNSChain’s censorship circumvention is in many ways superior to Tor’s!”

As far as I can tell, DNSChain is planning on selectively performing DNS hijacking; forwarding blocked sites to a transparent proxy. Of course, the user has to have a proxy that hasn’t been blocked and we are back to trusting “friends” to run this for you. As for comparing the project to Tor in terms of detection and the security model … I’ve learned that cranks don’t need to be correct, they just have to outrun the fact checkers. DNSChain isn’t doing anything special here, just making grandiose claims about some very vanilla technology.

No Usability Gains

Using DNSChain requires either installing software locally or altering your operating system’s DNS settings. The problem is that DNSChain’s client/server model will always be more complex than the equivalent scenario for a lightweight resolver:

• Effort required to manually install a lightweight resolver < effort required to maintain a DNSChain server + install and configure client software.
• Effort required to use a lightweight resolver bundled with browser/operating system < effort required to configure a DNSChain client software to use router that bundles DNSChain.

DNSChain throws away all of the security benefits of a lightclient without ANY gains in usability. However, I’m working on full an interoperability solution for .p2p (and hopefully .bit) that does not require altering any system settings or installing software. It’s not as secure a lightweight resolver (the preferred method) but the compromise is for major gains in terms of usability: anyone can link to and visit these sites!

Ideal Third Party Trust

By moving the trust mechanism outside of the local environment, you must introduce some form of third party trust. The essence of arguments against third party trust can be found in Ken Thompson’s classic Reflections on Trusting Trust, in which Thompson showed that an attacker can modify a compiler to produce malicious programs, including a rigged compiler that perpetrated the attack,

The moral is obvious. You can’t trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.

The counter to this argument came decades later in the form of deterministic build environments. Deterministic binaries enable us to compare the output of multiple compilers, increasing the attack cost. The exact security offered is a bit more robust than my summary, but the lesson forms the basis of modern information security: we cannot prevent all attacks, but we can make them very expensive.

I call this type of trust distributed trust, as the trust is distributed across independent entities. This is distinct from the type of trust offered by the CA system, unsigned DNS, or DNSChain, which I call siloed trust. Siloed trust accumulates vulnerabilities as more organizations are added, whereas distributed trust becomes more secure as more organizations are added. By distributing the trust across independent organizations, we increase the cost of an attack.

We are planning on setting up multiple publishers and using threshold signatures to produce DNSSEC secured zone exports. We will initially use a DNS suffix, for political reasons I can’t elaborate I can’t elaborate beyond the DNS suffix but anyone can use our signed zone exports².  Interoperability with existing DNS infrastructure and the limitations of DNSSEC forces some compromises. However, we can revoke trust in any of the publishers at any time and custom client side software can even add additional publishers.

This solution is more censorship resistant and at least as secure as what is offered by other TLDs. While we will have to rely on the certificate authorities until we can convince browser vendors to embrace DANE, we’ve architected the encryption component so that we can seamlessly transition to DANE³. Eventually, I believe that we can offer something that is more secure than what the other TLDs provide. Site operators who decide that they need greater levels of security can opt out of the system and rely on lightweight clients that are more secure and robust against censorship.

Collaboration

DNSChain has responded to my critiques by advertising multi-chain compatibility and paying lip service to collaboration. This is frustrating because DNSChain is diverting resources from Namecoin’s lightweight resolvers, NMControl, and my own interoperability work.

Both NMControl and the backwards compatibility solution are “multi-chain” efforts: I’ve been hired by BitShares, the only other major blockchain committing serious resources to a decentralized TLD. I know because I talked to Vitalik Buterin about potential collaborations and Ethereum isn’t interested in working on a decentralized TLD. In addition to the zone exports, we are working on harmonizing standards and porting NMControl to work with BitShares.

If DNSChain’s author wants to collaborate, he could lend a hand with NMControl or help build the trusted server solution I’m working on with Ryan. Greg is obviously great at marketing and has a lot of energy. Even if he doesn’t like programming in Python, there are plenty of other areas he could work with us on. At the very least, they should switch from trusting routers to the zone exports we will be publishing.

Bonus: REST API

DNSChain makes a lot of hay about having a REST API. This is pretty silly: REST is a great RPC for the web because of how it scales, but local clients are better off using a more powerful RPC library, like the one packaged with NMControl. If you must have a REST API for local software, NMControl is adding one⁴. We are working on with TLS encryption too, if you really want to run your own client/server setup, consider hacking on NMControl.

However, it’s fairly trivial for the publishers to export signed JSON records in addition to the DNS zone exports. I’m planning on importing the JSON records into a public CouchDB database. CouchDB’s REST based protocol enables it to scale like crazy and gives us a free REST API. CouchDB has client libraries in every major language, giving us free client libraries for the web service. There is even a browser-based, JavaScript implementation that does P2P using WebRTC! It’s also easy to setup a document schema that forces the client to check every record for the threshold signature.

My point is this: choose the right tool for the job. DNSChain is poorly architected because it’s trying to do everything at once. Our middleware, NMControl has the backing of the Namecoin team and we are working on making it compatible with BitShares and CouchDB has a large team of paid developers behind it. Why build a server and the middleware from scratch?

Conclusion

I agree that there should be a trusted server solution and I’m emulating a solution that has been deployed on a large scale and it offers backwards compatibility with the existing domain name system.  The core architecture uses a distributed trust model and is forward compatible with security improvements to internet infrastructure.

The problem with DNSChain is that they persist in making false, grandiose claims about a solution that involves everyone buying a plug-computer or a new router.  With DNSChain, we will get a large number of people locked into trusting their home router manufacturer, forever.

1. DNSChain will say that their model is (now) more secure since a user can change which servers they trust.

   This is similar (but not as absurd) to their claim that users will run their own servers.  How many people change the default directory authority servers on their Tor client?  I’ve talked to Tor developers, they are shooting from the hip when it comes to choosing routers.  Unlike Tor, DNSSEC signers aren’t making qualitative decisions on which routers to trust, it’s trivial for anyone to validate the resulting DNSSEC zone file.

   DPoS blockchains (like BitShares) control who produces the DNSSEC zone records and (unlike DNSChain) has a mechanism to pay them to perform this public service.  While only ~7 servers would be signing off on the DNSSEC records, the rest of the BitShares network can verify evidence of fraud and remove untrustworthy servers.

   DNSChain supports a version of public key pinning for all domains. However, security conscious websites should presumably be performing public key pinning on the server side.  But, again, if you are willing to install software to improve your security, setting up DNSChain requires at least as much work as installing a lightweight resolver and is also less secure. ↩

2. Including DNS service providers, ISPs, and router manufacturers.  Of course, if you are going to install something locally, you should just use a lightweight resolver. ↩

3. Again, politics is locking up the details for now. ↩

4. We actually already have one but the current implementation is insecure. That being said, we’ve peaked at DNSChain’s code and …. ↩

This content is password protected. To view it please enter your password below:

Password:

Introduction

I started contributing to Namecoin because I wanted to build an interoperability solution for .bit so that everyone could visit .bit sites without installing software or altering system settings.  I’ve spent the past couple of years working with my colleagues to systematically break down each one.  From legacy interop to inclusion with the major browsers to domain pricing to interoperating with registrars, I think we’ve architected a solution that will work.

My week at BitShares HQ was to give me time to grok BitShares’s security model, your team, and your community.  BitShares has solved some problems that Namecoin hasn’t, such as pegging assets to USD.  The BitShares’ community is also more open to my proposal for legacy interoperability.  Furthermore, I’m a convert to DPoS:, you can fuel a higher rate of innovation and the security model can accommodate my proposal for legacy interoperability.

However, I want to be upfront in my continued association with Namecoin.  I am a Namecoin contributor who also wants to become a BitShares contributor, but I am in no way being “poached” by BitShares.  Even if delegate pay could sustain me at a market competitive rate, I honestly wouldn’t be of much use without my continued collaboration with my colleagues in the Namecoin community.

Namecoin developers are all volunteers and we are eager to have others tackle this problem. Posts to our internal board regarding potential collaborations and my trip to BitShares HQ have been met with nothing but positive feedback.  The difference between Namecoin and BitShares is similar to that of Debian and RedHat or Firefox and Chrome.

My goal in collaborating with BitShares is to pool our resources and reduce duplication of effort.  Both projects need to work with the IETF, ICANN, certificate authorities DNS providers, and anonymity networks.  Having two parallel efforts tackling the same problem will increase our chances of success.  It’s time we start working together to end online censorship and make the internet safe from corrupt governments.

The Long Term Plan

Legacy Interoperability

Metcalf’s law ensures that .p2p sites must interoperate with the existing web, no website will link to a .p2p site unless all of their visitors can visit the site.  Asking users to install software or changing DNS settings is asking too much!

Initially, we will have to rely on a DNS suffix (i.e. p2p.tld) also known as a pseudo SLD.  However, we must make this solution as secure as traditional TLDs, which requires setting up threshold signing for DNSSEC and electing delegates to sign the zone file.  This task is non-trivial and there are several problems with BitShares original plans for the DNS suffix that I will cover later on.

This solution is not ideal in the long term, if a government shuts down our suffix it shuts down the entire TLD.  However, owning multiple backup .p2p TLDs will turn any attempt at shutting down the TLD into free marketing, the kind that pushes browser and operating system vendors to adopt lightclient resolution directly.

We will also publish signed zone files to Archive.org, so DNS providers can enable .p2p resolution and DNSSEC validating clients won’t have to rely on their DNS providers operational security.  In the medium term, I anticipate pushing .p2p resolution at third party DNS providers (like OpenDNS, Google’s DNS, etc.) as well as universities, major ISPs, and on corporate campuses.

There are several mechanisms (server side, client side, and on the browser level) for detecting support for direct .p2p resolution and forwarding clients from the suffix to the native .p2p domain. Thus, when clients support local resolution, existing DNS suffix links will resolve to the .p2p domain directly.

Local Lightclient Resolution

I interned at Mozilla and it is a crazy place to work.  The majority of the committers are unpaid and the majority of paid developers are remote, meaning that nearly every developer meeting is broadcast on the internet and that anyone can just drop in on the chat channel.  As a result, the noise floor is VERY high: there a lot of people demanding that Mozilla support various protocols and initiatives.

Take the Metalink project, a standard for listing multiple URLs and transports for a single download.  It has had patch sets for Firefox for years, pending RFCs at the IETF, it is used internally by YUM, supported by cURL, and offered as a distribution method for pretty much every major Linux distro.  It makes downloads faster and more resilient to failure … but Mozilla hasn’t adopted it.

That’s a very long-winded way of saying that we need an overwhelmingly strong case if we ever want adoption by the major browsers and operating systems.  Snowden and the US government’s domain name seizures have made our case much more compelling, but we need still need a few more tricks.

Zooko’s triangle is why I’m here: to make anonymous, censorship-resistant networks usable. Fulfilling this use case is what will enable us, in the long term, to be included in operating systems, browsers, and other network software directly.

Furthermore, China has essentially locked Google and every other Western company out of the world’s largest market.  Indeed, 55% of the worlds population lives in countries that engage in moderate to severe levels of censorship.  It is in these markets that users will be willing to install software add-ons to circumvent censorship and the profit motive to crack these walled gardens will be our vehicle to mass adoption.

The Plan for 2015

There are a number of problems with .p2p’s existing plans, mostly stemming from a lack of expertise in the relevant areas.  Collectively, it has taken the current Namecoin development team years to develop this expertise.  We also have connections to various communities  (DNS, certificate authorities, the security industry, and standards bodies) that the .p2p team lacks.  Hiring me as a delegate will give BitShares someone to head up this effort that has spent a lot of time reviewing the legal, technical, and usability issues at play.

With your official support, I will include explicit support for BitShares in all of my work and create parallel infrastructure for .p2p.  Let’s get down to what, exactly, that means.

Funding

I am requesting 2.5 delegates, one for myself, another for a security engineer and a third for operational expenses.  The operational expenses delegate will cover the cost of hiring a system admin to manage the delegates and additional expenses such as dedicated servers for the zone signers, .p2p domains, travel costs, and some code bounties for work I do not have time for myself.  I will regularly (probably annually) burn any additional funds that the operational expense delegate does not use.   All three delegates will be converted into zone signing delegates.

The proposal for 2015 is somewhat optimistic: delegate pay only covers me at ¼ of my industry pay rate (after self-employment taxes).  I am assuming that I will receive grant money to work on Namecoin ¾ time with delegate pay making up the other ¼ time and that the BitShares’ price will not fall dramatically.  If I do not receive grant funding or BitShares’ price falls dramatically, we will need to reevaluate my obligations and pay.

IETF, ICANN, & Domain Politics

I made a very stupid mistake in the first draft of this document: promising anything in regards to standards bodies.  I’m very new to both ICANN and the IETF but I do have contacts there and I am excited to start advocating on the behalf of .p2p.  However, if my time in politics taught me anything, it’s to be very humble in what you plan to accomplish.  I think I can provide value here, but do not hire me based on my expertise in this domain.

The operational expenses delegate will be used for any travel expenses to attend IETF and ICANN meetings ($3,000-$5,000).

Legacy Interop

DNS Suffix

We need several domains to try and prevent attackers from seizing our primary domain. Even with multiple fallbacks, we should try to use the domains most resistant to domain seizures.  I have a list of TLD’s that are cross referenced with the OpenNet Initiative as well as a FOIA request pending with ICE to help determine the safest alternative domains.  I will use this list to generate a list of potential TLDs and then negotiate the purchase of the domains.

Delegate pay will only cover my labor costs; the cost for the additional domains will need to come out from the operational expenses delegate ($1,000 per domain).

DNSSEC

We need to not only sign the DNS suffix but also publish signed zone files so that DNS providers (OpenDNS, Google’s DNS, universities, ISPs, corporate campuses, etc.) can enable .p2p resolution securely.  This is a very complex task.  The first engineering difficulty is that interoperability with DNSSEC means that we must implement a threshold signature scheme that can produce standard RSA public keys with signatures that can be verified by the standard verification routines.  The second is that since we are talking to standard DNSSEC equipment we can’t rely on the normal delegate consensus system.

Thankfully, an academic has published a paper outlining a scheme that produces standard RSA signatures.  There was apparently a Java implementation, but we have been unable to contact the author.  If we cannot get a hold of an existing implementation, we may need to hire a mathematician to help with the reimplementation.

Finally, we must create a system that parallels the traditional TLD zone signing scheme.  The proposed threshold signature scheme’s complexity scales linearly with the number of parties, so it is not feasible to use to scale to a full 101 delegates.  Furthermore, since we cannot easily replace delegates (revoking one delegate requires generating a new ZSK and signing it with the KSK) we need to select a smaller number of very reliable delegates.

The system will require the generation of a Key-Signing-Key (KSK) with 7 trusted parties that store their keys offline.  The KSK will sign a Zone-Signing-Key (ZSK) that is used by delegates to sign the zone files.  We can use a 2Kb ZSK, so there is no need to create and sign a new ZSK every 3 months (.com, .net, etc. use a 1Kb ZSK).  However, to protect against governmental adversaries, the zone signers will need to use dedicated servers and store their keys in hardware security modules.

Delegate pay cover the initial threshold implementation, creating a hardened Linux system, and setting up demonstration zone-signing delegates.  The threshold signature implementation and creating demonstration delegates (including a locked down image and sysop automation) will be covered by the security engineer’s 100% delegate for one year.  The operational delegate will increase its pay rate as needed to cover the demonstrations servers hardware costs (~$2,500).  Sometime in 2016, we will choose the final trusted KSK holders and the additional zone-signing delegates before officially launching .p2p.

Development

There is a lot of development work unrelated to the backwards interoperability proposal.  This includes work on domain record specification, middleware, and clients to manage domains.

Name records must be converted to a destination format.  For example, a domain might need to be converted for use by Plain-Old-DNS (PODNS), Tor, I2P, etc.  The names and their records must go through validation checks.  Finally, operating systems, browsers, and other applications also need the records served up via DNS; necessitating a standards compliant DNS server.  These tasks fall to a middleware layer that lives outside of the blockchain software.

Delegate pay will primarily fund making Namecoin’s middleware (NMControl) compatible with BitShares.  However, I would also like to convert NMControl to Python 3, replace the RPC library, add record validation, build client libraries in 5+ languages, and add full test coverage.  The resulting product will work with Namecoin’s browser and system level proxy solution and serve for other applications that wish to communicate directly.

I will also be working on important usability issues regarding domain name ownership.  For example, we need to refactor how TLS signing works.  Right now, sites can generate multiple TLS certificates and have them signed by a certificate authority.  We need to transition to a system in which site owners sign their site certificates with an master key pair that is stored offline.  Setting up a domain management client to handle these items automatically is going to take a significant amount of work.

I have little experience with Python, I am unfamiliar with the codebase, and I will work on this in parallel to my other responsibilities.  Given the level of unknowns, I am going to give myself a wide margin of error and estimate the time for completion of this task to be 6-12 months.

Given that delegate pay is only covering me at ¼ time, this estimate dependent on Namecoin providing additional funding for me through grants or from the community contributing to code bounties.  Delegate pay will enable me to survive until such funding comes through.

Internet Freedom Alliance Working Group

There is a need to harmonize standards between BitShares and Namecoin namespace specifications.  There is also potential for collaboration between other groups, such as Tor, I2P, and Freenet.  To facilitate these goals I will create and administer the Internet Freedom Alliance: a working group dedicated to harmonizing standards and increasing collaboration.

The group will largely consist of a mailing list and a Github organization with repositories for formal specifications, unit tests, and reference implementations.  A RFC process for proposing revisions and new standards will be created based on Bitcoin’s BIP workflow and existing standards will receive a formal write up.  The IFA-WG will register as a non-profit legal entity to receive funding from member projects as well as donations.

.p2p Prelaunch

I’ve worked out a general plan for name reservations, pricing, and other details during my week at BitShares HQ.  However, as the BitShares team can attest, the reasoning for each decision is complex and the full plan will be outlined at a later date.  However, we will create an experimental second-level-domain, x.p2p and progressively enhance it’s capabilities.  This will allow us to test software, such as the middleware and browser add-ons.

I will also work with DNS service providers to build an abstraction layer that will allow registrars to purchase domains using their existing infrastructure.

Beyond 2015

The majority of the work outlined above should be finished by the end of 2015.  I suspect that over the year, the core development team will be able to switch their focus to features like transaction anonymity, advanced light clients, and setting up the launch of .p2p in early or mid 2016.

It may, at some point, make sense to create a new DAC optimized as a trusted base. There is concern that BTS might not be perceived as “neutral” enough to be a trusted base for core internet infrastructure. It would also make sense to increase the time interval between blocks.  Finally, it may be easier to adopt ZeroCash and other future proposals using a different codebase.  However, in the near term, setting up 101 new delegates, getting adoption in the exchanges, and setting up a competing BitUSD market is just not feasible.

Should it end up being the case that we cannot use the BitShares blockchain, we can always share drop onto BTS for both the share allocation and the initial name ownership. As long as BTS holders benefit from selling the namespace in what eventually becomes a secure decentralized DNS solution, everyone should be satisfied.

It’s impossible to predict the future, and we should evaluate my contributions and potential future as a delegate when 2016 rolls around.  The entire crypto market could tank, or someone could exploit a design flaw so severe that we the couldn’t recover.  Hopefully, I will find external funding, I could be accepted into a Ph.D. program and comfortably work part time for BitShares, or BitShares could explode and I could support myself on delegate pay entirely.

Conclusion

I’ve laid out a comprehensive plan for both near-term and long-term adoption of .p2p.  I outlined cost estimates for the near-term future and options should the funding situation change.  In the future, it may make more sense to design a currency tailored specifically as a trusted base and share drop on BitShares.  With your support, I believe we can enable universal .p2p resolution thus ending the threat of domain name seizures and making anonymous networks usable.

Donation Addresses

• BitShares ID: indolering
• Bitcoin Donation: 1DKG4wMB4fQfgB5W5qFjrtMXHkZJKL37ua
• Namecoin Donation: N3ramRzMjm791aGUyg5DQFSupFijVwCCEf

Update

I’ve written a more-up-to-date technical overview of okTurtles, DNSChain, and Unblock.us. While the security model for DNSChain has improved, they are still misrepresenting the security parameters of their software.

I’m leaving this here because they are still selling PlugPCs as a valid solution to eliminating third party trust from their security model.

Background

DNSChain is essentially a DNS server which reads data from the Namecoin blockchain.  It is highly duplicative of NMControl (Namecoin’s chosen middleware) with the exception that it initially focused on a pure client/server model.  Any client/server model introduces third party trust, seriously degrading the trustless nature of the Nakamoto blockchain and introducing MITM attacks.

We actually don’t have a problem adding this functionality to NMControl. The problem is that DNSChain’s lead developer is claiming that DNSChain doesn’t introduce third-party trust and is “MITM Proof.”  Their rationale is that if someone isn’t capable of running their own server, a friend would run one for them.  This is impossible to scale and is akin to claiming that everyone would run their own email server.  They tried to dodge the fact that they effectively introduced third party trust by using the term “second-party trust.”

I wrote a blog piece and pushed DNSChain to use lightweight clients instead.  The author came back with a new security model which is similarly difficult to scale and effectively introduces third party trust.  This post analyzes their new security model.

Home Based Servers: Unnecessary and Infeasible

DNSChain’s lead author responded with a comment giving an update to their security model, excerpted below.

The vast majority (“99%” :-P) of families in Internet-connected countries own and run their own servers (which run DNS software like BIND, etc.), and they do so without realizing they are doing it.

This is nothing out of the ordinary, and it is the model we see working for DNSChain as well. This is what we mean by trusting themselves or a “first party”. The use of the word “friend” refers to an _interim period_ before DNSChain appears on home routers.

This “friends” terminology is weasel wording and it misrepresents their security model. That’s not okay, even if it’s not a permanent part of their plan.

This modified plan involves an infeasible and insecure scheme that turns every home router into a server and the anchor of our security systems.  Everyone will have to buy a PlugPC or a router with Namecoin installed which their clients can connect back to.  10% of American’s don’t have a home internet connection and the third world will likely skip out on wired internet entirely.  Even if we ignore the feasibility of this plan, DNSChain still offers no improvements to usability, inter-operability, or security over lightweight resolvers.

The Namecoin development team also has aspirations for lightweight resolvers to be bundled with browsers and operating systems.  The difference is that users never have to configure a client to talk to a trusted server or any kind of maintenance, it will just work.  DNSChain’s client/server model will always be more complex than the equivalent scenario for a lightweight resolver:

• Effort required to manually install a lightweight resolver < effort required to maintain a DNSChain server + install and setup client software.
• Effort required to use lightweight resolver bundled with browser/operating system < effort required to configure DNSChain client software to use router that bundles DNSChain.

Even if we ignore the fact that lightweight resolvers will always be easier to use than DNSChain’s client/server model, this modified plan would never scale outside of a single percentage point of the population.  Turning routers into trusted servers sounds like something cooked up by a sys-admin who thinks s/he can make server maintenance “usable”, which won’t happen.

Practically speaking, routers are not like normal servers and they certainly cannot handle a full Namecoin node.  Normal routers aren’t going to accommodate a full Namecoin node, so every existing router would need to be replaced.  By asserting that routers will adopt DNSChain and run a full-node Namecoin install, Greg is not just asserting that router vendors will adopt their software but also add the processing and storage capacities of a small server.  Even then, home users would have to regularly increase disk capacity since the Namecoin blockchain increases in size over time, thus DNSChain’s revised plan requires lightweight resolvers anyway.

The fact of the matter is that no one is going to operate a server from their home. Residential internet connections are flaky, I have to reset my modem and router several times a year.  What happens when their connections fails while the user is not at home or when a roommate bogs down the connection with a torrent?  Nor does everyone have a home with a stable internet connection: rural users rely on long-haul wifi or satellite links.  Furthermore, the third-world is coming online using their mobile devices, and they often lack a home router.  Setting up wifi passwords is a major challenge for many users, there is no way users are going to manage the complexities of maintaining this client/server model.

Furthermore, home routers are not the bedrock we should be anchoring our security too.  The market ensures that consumer routers are produced as cheaply as possible and they are rarely ever updated.  Even commercial grade routers are prime targets for the NSA’s efforts to recover VPN keys.  DNSChain is assuming that router manufacturers are going to start producing rock-solid routers that requires zero maintenance.

Finally, anyone without a home internet connection will need to trust someone else.  The problem with DNSChain’s modified plan is that it operates under the assumption that the next generation netizens will look like the last generation.  But that’s not the case, time spent on mobile internet devices has already eclipsed that of desktops.  The third world is leapfrogging traditional land-line phones and going straight to cell phones, and they will likely leapfrog the first world by coming online through smartphones.  Finally, some really people figured out how to take the noise out of Shannon’s information channel theorem, which means that wireless internet is about to get reall, really fast. So, even with magical routers and and 100% uptake amongst those with residential internet connections, the majority of the worlds population will need to trust someone else.

Lightweight resolvers always beat out DNSChain’s client/server model, even if the server part is magically taken care of by bundling DNSChain with home routers.  That magic also requires making residential internet connections and routers rock solid, which won’t happen in a market dictated by prices. Lightweight clients are part of the magic requires to load Namecoin on routers would require, so DNSChain requires lightweight resolvers anyway.   And, finally, even with all that magic, DNSChain would still render vast swaths of the population dependent upon the worst kind of third party trust.

FWIW, in a follow-up discussion on IRC, Greg was open to lightweight resolvers but skeptical of their feasibility.   The problem is that building a bullet proof router and getting everyone to buy one or convincing router manufacturers to increase their build cost are two scenarios that are a few orders-of-magnitude more difficult than building advanced lightweight resolvers.  I’d be happy to welcome Greg in if he wants to join us, but DNSChain is just diverting resources from projects and people who are proposing real solutions to these problems.  Even then, he’s got to prove himself capable of building something that can actually work.

It’s tough to knife one’s own baby, I’m having to do that to some extent with Speech.is: the legal assumptions under which I created it two years ago just doesn’t hold up anymore and the additional effort isn’t worth it.  Creating a DNS suffix with threshold DNSSEC is a better zero-install/zero-config alternative.  Namecoin devs are still skeptical but that’s what BitShares wants me to help them accomplish with .p2p.  But it’s just a pivot, our early plans are rarely wholly correct.