[cabfpub] DV issuance for next-generation onion services

Fri Nov 3 00:14:55 UTC 2017

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