[cabfpub] DV issuance for next-generation onion services

Hi folks, My name is Seth Schoen, and I work at the Electronic Frontier Foundation (EFF) in San Francisco. We've recently joined as an Interested Party. Although we work closely with ISRG, I'm speaking for and representing only EFF, not Let's Encrypt. (I've been a cabfpub subscriber for several years, but I didn't previously represent an Interested Party, so I wasn't allowed to post.) In this message, I suggest passing a ballot to allow DV issuance for onion names, now that next-generation onion names are here. I would like to see what the membership thinks about this topic. Nature and status of onion names -------------------------------- As a recap, onion names are a kind of identifier defined by the Tor software for what the Tor project now calls "onion services". There was some controversy about the fact that this identifier is a DNS-style name not registered by ICANN or reserved by IANA, which could create potential collision between these names and DNS names in a hypothetical future .onion TLD, and, in 2015, RFC 7686 ("The '.onion' Special-Use Domain Name") reserved .onion as a Special-Use Domain Name in order to remove this ambiguity. One of several rationales for the adoption of this RFC was to make it possible for onion identifiers to be used in digital certificates without leaving the subject of the certificate be ambiguous in a way that could create a security risk. An unusal property of onion names compared to many other identifiers used on the Internet is that they aren't assigned by an authority or registry, but are self-authenticating names directly derived from a cryptographic key (by applying a cryptographic hash to a public key and then truncating the hash output). For some purposes, this provides a convenient way to combine routing and authentication attributes within a single identifier. In the original version of the Tor rendezvous specification, the onion name was defined as a textual (base32) representation of the first 80 bits of a SHA-1 hash of an associated public key. https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n527 A familiar example is "facebookcorewwwi.onion", which Facebook was able to obtain by trying an extremely large number of key parameters and examining those whose textual hash representations began with the string "facebook". Although this identifier has the format of a domain name, RFC 7686 says that it should not be resolved through the DNS. Instead, onion-aware software can perform an elaborate "rendezvous" process to reach a service that possesses a matching private key via the Tor network. The method of calculating these identifiers was criticized by various parties (including some members of this Forum) both for using the obsolete SHA-1 hash and for truncating the hash value to 80 bits, which would also reduce the cost of finding a partial hash collision. The Tor Project subsequently adopted a next-generation rendezvous technology for onion services. Among other changes, this technology significantly improves the security of onion names. In the next-generation onion services specification, onion names now contain the service's entire explicit public key, rather than a truncated hash of the key. (I'll refer to these as "NG onion names" and "NG onion services".) https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n408 As a result, NG onion names are 56 characters (excluding the ".onion"), while old-style onion names are only 16 characters. The specification notes that An older name might look like: unlikelynamefora.onion yyhws9optuwiwsns.onion And a new name following this specification might look like: l5satjgud6gucryazcyvyvhuxhr74u6ygigiuyixe3a6ysis67ororad.onion The reason that the old-style name "unlikelynamefora.onion" is described as "unlikely" is that a service would need to generate and examine an average of 2⁸⁰ candidate public keys to find one that would be identified this way. This is a lot of work, but on the other hand it currently represents less than two days of the hashing power of the Bitcoin network and wouldn't be considered a reasonable work factor for security in a modern cryptographic design. NG onion names were observed in active use on the Tor network starting in September 2017, and the Tor Project made a blog post earlier today letting the larger community know that they're available: https://blog.torproject.org/tors-fall-harvest-next-generation-onion-services Historical concerns about certificates for onion names ------------------------------------------------------ The Forum has adopted either two or three ballots that relate to onion names (ballots 144, 198, and 201). All of them were sponsored by DigiCert, which is the only CA to have issued certificates for onion names that are visible in Certificate Transparency logs. So far DigiCert has issued about 2200 such certificates for a few dozen organizations. The existing ballots proposed to allow issuance for onion names (as an exception to the general rule that a subject dNSName must be a subdomain of a top-level domain in the public DNS system) only in the case of EV certificates. One rationale for this limitation was a suggestion that onion names were created by a cryptographically weak method due to the use of a truncated SHA-1 hash, and that there was a cryptographic strength mismatch with the rest of the cryptography in the web PKI, which is much stronger. The identity verification performed as part of the EV process was supposed to mitigate this risk by requiring certificate applicants to be strongly, publicly identified. This rationale should not apply to NG onion names, which use strong, modern cryptographic primitives and directly represent the onion service's entire public key within the onion service identifier. Why do people want certificates for onion names? ------------------------------------------------ Since NG onion names are self-authenticating and directly deliver a public key that must be used when connecting to a service, it might appear that a PKI is superfluous for confirming the authenticity of an onion service. However, it was already clear from the EV case that some organizations definitely want these certificates. People have also repeatedly asked Let's Encrypt about the possibility of DV issuance for onion services, so there's also interest from would-be subscribers. The authentication provided by onion names, from one point of view, happens at a lower layer than authentication of a TLS session. To an application, it can be seen as a network-layer authentication (and confidentiality) service, effectively operating below the TCP socket level. While network-layer authentication is great and can provide excellent security, it may be a mismatch for security features that have been designed to expect authentication to take place at a higher protocol layer. In today's web browsers, quite a lot depends on HTTPS support. Using HTTPS on onion sites makes browser code simpler and cleaner in various ways, including by not having to make exceptions for policies and code paths that require certain things to be HTTPS-only or display security warnings for particular features on HTTP origins. It also makes things much simpler and clearer for end users who might use onion sites but not be aware of the details of cryptographic security properties that Tor does or doesn't provide. It also makes things simpler for sites that provide a clearnet and an official onion site version of the same site, because HTTPS can consistently be used across both site versions. (Issuing a certificate for the onion site in this case can also qualitatively improve the security properties of such a site when the onion service and the web server aren't hosted on the same machine or the same network, because the Tor-provided encryption terminates on the onion service machine, while the HTTPS-provided encryption, if present, terminates on the web server. Without an HTTPS layer, all the traffic between the onion service machine and the web server would be plaintext -- which might be quite reasonable if they're on the same machine, yet dangerous if they're not.) And it makes things simpler for people trying to provide security education to end-users, because when onion sites can go HTTPS, there's no need to teach the more complicated rule "You should always try to access the secure HTTPS version of a site -- unless it's an onion site". Finally, site operators who specifically want to achieve a linkage between clearnet names and onion services might choose to use a certificate in some way to show that a particular onion service is operated by the same entity that controls a particular Internet domain name. Conceivably, a new policy OID could indicate that the site operator recommends switching to an onion service when possible; eventually, browsers that support onion services could recognize this and switch automatically. (Of course, the availability and success of mechanisms like this isn't necessary for onion sites to start benefitting from certificates.) EV isn't a practical option for all onion services because some of them are operated by individuals, not legally incorporated organizations. What's more, many onion service operators are anonymous and don't want to reveal their legal identity. Conclusion ---------- I would like to invite discussion of the prospect of a future ballot extending the current Ballot 201 permission to issue EV certificates for .onion names to also permit DV issuance -- otherwise following existing BR rules on allowable DV validation methods wherever any of the allowed methods can reasonably be applied to validating control of an onion service -- for subject names that are NG onion names. It would be great to hear Forum members' opinions on this topic. -- Seth Schoen <schoen at eff.org> Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107