<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 19, 2014 at 12:26 PM, Brian Smith <span dir="ltr"><<a href="mailto:brian@briansmith.org" target="_blank">brian@briansmith.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Gervase Markham <<a href="mailto:gerv@mozilla.org">gerv@mozilla.org</a>> wrote:<br>
> I'm in support of this in principle. There are two issues with 'normal'<br>
> internal server names:<br>
><br>
> 1) It's not possible to prove exclusive ownership of them (because they<br>
>    aren't exclusively owned);<br>
<br>
</span><snip><br>
<span class=""><br>
> For .onion names, problem 1) does not apply.<br>
<br>
</span>That is only true assuming you can rely on the second-preimage<br>
resistance of truncated SHA-1, like Ryan pointed out. I think his<br>
point is that the second-preimage resistance of truncated SHA-1 is not<br>
strong enough to make claims like this. (Ryan: Sorry if I'm<br>
misunderstanding you. Corrections appreciated.) I think that concern<br>
should be addressed. This is one reason I suggested to limit the<br>
maximum lifetime of .onion certificates.<br>
<br>
Cheers,<br>
Brian<br>
<div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>Correct. And it's something the TOR team have known about for a while (c.f. <a href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-what-uses-sha1.txt">https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-what-uses-sha1.txt</a> ). Also, let's not forget that "attacks get better" - <a href="https://www.schneier.com/paper-preimages.html">https://www.schneier.com/paper-preimages.html</a> was 2^106 against full SHA-1.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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 </div></div><br></div></div>