[cabfpub] .onion proposal

[Ryan Sleevi]

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

> Gervase Markham <gerv at mozilla.org> wrote:
> > I'm in support of this in principle. There are two issues with 'normal'
> > internal server names:
> >
> > 1) It's not possible to prove exclusive ownership of them (because they
> >    aren't exclusively owned);
>
> <snip>
>
> > For .onion names, problem 1) does not apply.
>
> That is only true assuming you can rely on the second-preimage
> resistance of truncated SHA-1, like Ryan pointed out. I think his
> point is that the second-preimage resistance of truncated SHA-1 is not
> strong enough to make claims like this. (Ryan: Sorry if I'm
> misunderstanding you. Corrections appreciated.) I think that concern
> should be addressed. This is one reason I suggested to limit the
> maximum lifetime of .onion certificates.
>
> Cheers,
> Brian
>
>
Correct. And it's something the TOR team have known about for a while (c.f.
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-what-uses-sha1.txt
). Also, let's not forget that "attacks get better" -
https://www.schneier.com/paper-preimages.html was 2^106 against full SHA-1.

This is not something we (The Forum) can solve, as it's fundamental in the
TOR protocol. But the goal of deprecating internal server names is to
ensure that the only publicly issued certificates are for verifiably-unique
names. For all IANA-delegated gTLDs/ccTLDs, this is true, as per DNS. For
the reserved names - whether .home, .corp, or schemes like .onion - this is
not intrinsically true.

For .onion to be suitable for issuing certificates, we should have
relatively strong confidence that the names are unique. The EV requirement
is just a rehash of the past discussion for internal server names and them
being "OV vetted", so they were "good enough" (a point the browsers
disagreed on). In the absence of guaranteed uniqueness of .onion names (and
instead just strong assurances), then it may be useful to explore what UAs
such as Tor Browser can do to bind _additional_ metadeta that the CA vets.

For example, if binding to foo.onion was insufficient (since multiple
entities may contain foo), a way to express either at the protocol or
browser level a binding such that the UA can know/programatically enforce
that foo.onion is "The entity Foo Corp". Or we could just throw our hands
up in the air and say "caveat RP", and that it's now "user error" for not
checking whatever special UI signal they're supposed to know to ensure it's
"Foo Corp" and not the NSA/BSI/5EYES/BLACKHELICOPTERCORP they're talking to
when talking to foo.onion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141119/02e95ceb/attachment-0003.html>