Biblio

The Domain Name System (DNS) is part of the core of the Internet. Over the past decade, much-needed security features were added to this protocol, with the introduction of the DNS Security Extensions. DNSSEC adds authenticity and integrity to the protocol using digital signatures, and turns the DNS into a public key infrastructure (PKI). At the top of this PKI is a single key, the so-called Key Signing Key (KSK) for the DNS root. The current Root KSK was introduced in 2010, and has not changed since. This year, the Root KSK will be replaced for the first time ever. This event potentially has a major impact on the Internet. Thousands of DNS resolvers worldwide rely on this key to validate DNSSEC signatures, and must start using the new key, either through an automated process, or manual intervention. Failure to pick up the new key will result in resolvers becoming completely unavailable to end users. This work presents the "Root Canary", a system to monitor and measure this event from the perspective of validating DNS resolvers for its entire nine-month duration. The system combines three active measurement platforms to have the broadest possible coverage of validating resolvers. Results will be presented in near real-time, to allow the global DNS community to act if problems arise. Furthermore, after the Root KSK rollover concludes in March 2018, we will use the recorded datasets for an in-depth analysis, from which the Internet community can draw lessons for future key rollovers.

Currently, no major browser fully checks for TLS/SSL certificate revocations. This is largely due to the fact that the deployed mechanisms for disseminating revocations (CRLs, OCSP, OCSP Stapling, CRLSet, and OneCRL) are each either incomplete, insecure, inefficient, slow to update, not private, or some combination thereof. In this paper, we present CRLite, an efficient and easily-deployable system for proactively pushing all TLS certificate revocations to browsers. CRLite servers aggregate revocation information for all known, valid TLS certificates on the web, and store them in a space-efficient filter cascade data structure. Browsers periodically download and use this data to check for revocations of observed certificates in real-time. CRLite does not require any additional trust beyond the existing PKI, and it allows clients to adopt a fail-closed security posture even in the face of network errors or attacks that make revocation information temporarily unavailable. We present a prototype of name that processes TLS certificates gathered by Rapid7, the University of Michigan, and Google's Certificate Transparency on the server-side, with a Firefox extension on the client-side. Comparing CRLite to an idealized browser that performs correct CRL/OCSP checking, we show that CRLite reduces latency and eliminates privacy concerns. Moreover, CRLite has low bandwidth costs: it can represent all certificates with an initial download of 10 MB (less than 1 byte per revocation) followed by daily updates of 580 KB on average. Taken together, our results demonstrate that complete TLS/SSL revocation checking is within reach for all clients.