Self-Authenticating Traditional Domain Names

We introduce Self-Authenticating Traditional (SAT) domain names. SAT domains are traditional recognizable domains resolvable via the Domain Name System (DNS). They are also self-authenticating—they encode in the name itself a public key for authenticating the SAT domain. We present an implementation of our SAT domains for servers and a corresponding Firefox WebExtension that validates connections to them. SAT domains weave security directly into the fabric of the Web by building authentication into URLs themselves. Thus, by simply posting links to other SAT domains, a SAT site that a user trusts assures that user of the ability to make hijack-resistant connections to any of those domains. Because just the address attested in this way is sufficient for users to create a secure connection to a recognizable domain, we call this dirt simple trust. We present implemented examples of this and describe other channels to establish dirt simple trust. The public keys we embed in SAT domain names are in the format of Tor onion service keys. Specifically, a SAT domain includes the encoding of an onion service public key as a subdomain of a registered domain name. But the client can be ignorant of Tor and need not direct traffic over any onion routing network to obtain our protections. This makes SAT domains compatible with other browsers and standard routing infrastructure. Nonetheless, our extension also works in Tor Browser. We also explore systems developed and deployed by others that associate a self-authenticating domain with a traditional DNS domain using existing Web authentication mechanisms, but without building security in directly. Recently, major providers have deployed. onion alternative services to support load balancing and improved performance for Tor users. Though superficially similar to SAT domains, our analysis indicates that these alternative services are not actually self-authenticating. They also increase the effectiveness and impact of client tracking attacks acknowledged in the design of alternative services. We describe such attacks and describe another benefit of our WebExtension: it provides an interface allowing users to selectively block or permit alternative services.