<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 19, 2014 at 1:27 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Nov 19, 2014 at 12:52 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>> wrote:<br>
> It's hardly a slap in the face - it's a recognition of the security risks of<br>
> allowing .onion names to be a wild-west free for all with no vetting -<br>
> meaning ANYONE can MITM / any CA can issue for<br>
> <a href="https://facebookcorewwwi.onion/" target="_blank">https://facebookcorewwwi.onion/</a>  without violating a single one of the BRs<br>
> or any root policy.<br>
<br>
</span>Is it really necessary to revoke the facebookcorewwwi.onion<br>
certificate? If no new certificates could be issued, then the<br>
second-preimage resistance issue wouldn't be a problem for it, right?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The CAs and businesses that want .onion certificates should sit down<br>
with (and probably fund) the developers of Tor to add support for<br>
names with stronger second-preimage resistance, and present that plan<br>
to CAB Forum, so that CAB Forum can make a reasonable decision about<br>
how to make certificates for Tor hidden services work.<br>
<br>
Cheers,<br>
Brian<br>
</blockquote></div><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div>