[cabfpub] .onion proposal

[Ryan Sleevi]

On Wed, Nov 19, 2014 at 1:27 PM, Brian Smith <brian at briansmith.org> wrote:

> On Wed, Nov 19, 2014 at 12:52 PM, Ryan Sleevi <sleevi at google.com> wrote:
> > It's hardly a slap in the face - it's a recognition of the security
> risks of
> > allowing .onion names to be a wild-west free for all with no vetting -
> > meaning ANYONE can MITM / any CA can issue for
> > https://facebookcorewwwi.onion/  without violating a single one of the
> BRs
> > or any root policy.
>
> Is it really necessary to revoke the facebookcorewwwi.onion
> certificate? If no new certificates could be issued, then the
> second-preimage resistance issue wouldn't be a problem for it, right?
>

Well, we have no knowledge of what CAs have issued for it, which would be
the reason for revoking. That is, we have zero reason to believe that a CA
hasn't issued a cert for facebookcorewwwi.onion (which would be totally OK
for them to do, with zero special vetting req's). This is the same reason
we want to (eventually) revoke internal server name certs.

Now, it happens that .onion names have an added defense beyond the PKI
system - namely, that the only party who can MITM facebookcorewwwi.onion is
the holder of (the, a) private key that hashes to those 80 bits. This is
different than other systems (such as DNS), where anyone on the network can
MITM.

So no, strictly speaking, it's not necessary to revoke
facebookcorewwwi.onion, any more than it'd be necessary to revoke
foo.onion, beyond the fact that there exists no agreed upon way to verify
the holder. Leaving the existing certificates issued creates confusion as
to when any new standards come into play.

Put differently, if we do standardize .onion issuance (and I see no reasons
why we can't, just challenges we need to address while doing so), I would
want to see all existing .onion certs gone at (roughly) the same time we
set forth new standards for issuing them, so we should especially be
careful about encouraging a proliferation of them.


>
> The CAs and businesses that want .onion certificates should sit down
> with (and probably fund) the developers of Tor to add support for
> names with stronger second-preimage resistance, and present that plan
> to CAB Forum, so that CAB Forum can make a reasonable decision about
> how to make certificates for Tor hidden services work.
>
> Cheers,
> Brian
>

Agreed. This requires multiple stakeholders - CAs, Browsers, the Tor
developers (at the protocol level), the Tor developers (at the browser
level), and operators of Tor hidden services.

For example, a Tor HS cannot use CAA to restrict which CAs can issue for it
(since CAA depends on DNS), although they CAN use HPKP (since HPKP uses an
HTTP header). These are things that would need to be discussed more
broadly, arguably.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141119/53e09085/attachment-0003.html>