Event

<p>Public certificate authorities in TLS are a security liability from both a censorship and MITM perspective. Conceptually, DNSSEC's idea of tying PKI to domain names should be a better replacement -- except that in the DNS, relying on the names means trusting the registrars, registries, and ICANN. But what if we had <em>self-authenticating</em> domain names? Could we build a PKI on top of those? Could such a PKI work with unmodified mainstream web browsers like Chromium, Firefox, and Tor Browser?</p> <p>We've done exactly that. Namecoin (a blockchain naming system providing the .bit TLD) and Tor (an anonymity network providing the .onion TLD) provide the self-authenticating domain names. This talk covers how we made the PKI. Topics to be discussed include:</p> <ul> <li>Why public certificate authorities are dangerous.</li> <li>Prior work on using DNS as a PKI (and why it's less useful for us than you might think).</li> <li>How we creatively used API's to get mainstream TLS implementations to use Namecoin to validate TLS certificates.</li> <li>Why you might want to use TLS with Tor onion services (and why onion service encryption might not be as secure as you think).</li> <li>How we generalized Namecoin TLS to work with Tor onion services.</li> <li>How we made TLS implementations that don't support Ed25519 work anyway with Tor onion services (which rely on Ed25519).</li> <li>How we can use TLS with Namecoin without putting a TLSA record on the blockchain (for better scalability).</li> <li>How Namecoin's smart contract functionality (allowing multisig and timelocks to control updating a name) interacts with PKI use cases.</li> <li>How we generalized Namecoin and Tor PKI to work with non-TLS protocols.</li> <li>How revocations can be handled securely.</li> <li>How we ensured anonymity (including Tor stream isolation) despite TLS implementations not providing API's for this.</li> </ul>