[cabfpub] Ballot 144 -.onion domains

[Ryan Sleevi]

On Feb 12, 2015 12:43 PM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:
>
> Jeremy and Ben – sorry we didn’t ask these questions last week, but I was
travelling and didn’t realize the comment period had begun.
>
>
>
> (1) We are concerned that under  Ballot 144 there could be two .onion
certs with the SAME domain but identifying two DIFFERENT subjects.
>
>
>
> For example, Evil Corp. and Angel Corp. could each submit a request for a
.onion cert and get the same domain: [same 16 digit hash of their public
keys].onion if their public keys hash to the same value.  One cert would
say O=Evil Corp. the other would say O=Angel Corp., so that a .onion domain
would not be uniquely identified with one subject.  While unlikely, it
could happen.
>
>
>
> How does Tor resolve this if the same .onion domain is assigned to
multiple, different subjects?  If someone types in [16 digit hash].onion
and that could lead to multiple Tor locations, how does Tor decide where to
direct the user?
>
>

Hi Kirk,

While not Jeremy, this is actually why I suggested that the full public key
be included within the issued certificate itself, so as to highlight any
hash collision attempts on the onion private key (e.g. by funkily encoding
key parameters or by using key confusion). On a practical level, it's far
out there from the realm of being feasible, but it's enough of an issue
that I felt important that this should be included in the issued cert, so
that sites could use, for example, certificate transparency to monitor for
such things. On the TOR side, the protocol is being revved to deal with
this, but it is described more at
https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames

So from the issuance side, the mitigations are including the full public
key as well as requiring the EV validation, rather than DV.

>
> (2)  Does this also create an opportunity for a hacker?  For example, one
of the .onion domains in the SANs field of the Facebook cert you created is
*.xx.fbcdn23dssr3jqnq.onion – could a hacker create a public key that would
hash to the same value in order to get a cert with the same .onion domain
and imitate the Facebook cert?  (This is maybe the more serious case.)
>

Isn't this a restatement of 1? Or at least, the answers there would still
apply.

> (3) Another concern is there is no central registry to identify the owner
of a .onion domain (of course, there could be multiple owners of the domain
under the scenario above).  If there is no Subject info in the O field,
etc., with no registry there is no real way to contact the domain (or cert
owner).
>

I'm not entirely sure I follow? Note during the discussion phase also
included discussion about requiring one or more DNS names from the IANA
zone as well, which seems like it would mitigate this concern.

>
>
> Any information you can provide on these point will be very helpful.
>

I think it is important when considering these that, as of today, any CA
can issue any name under .onion under the "Internal Names" exception. This
proposal merely restricts it from being "any rules you want" to "more
stringent verification required"

It still treats .onion as an internal name, in as much as they still sunset
and must be revoked.

If this ballot fails, every CA will still be able to issue .onion names to
any party they wish, including parties who have no relationship whatsoever
to the onion HS. That is, if this fails, there is no requirement for
attackers to execute a hash collision or factor a private key - they just
need to find a CA willing to issue under the "Internal Names" rule (which,
as you know, is typically validated at a level less than EV, such as OV).

That's why I think this ballot is good - it doesn't prolong or extend risk,
it actually _restricts_ issuance in this space until internal names are
sunset, at which point, no more of these certs will be issued, no matter
the rules. In practice, I expect discussion and standardization to
continue, and we may see DigiCert issue a ballot in half a year that looks
to extend such issuance, but that's not this ballot, thankfully, so we
don't have to solve all of these issues right away.

>
>
>
>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is
confidential
> and may be subject to copyright or other intellectual property
protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply
mail or
> telephone and delete the original message from your mail system.
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150212/e49ec60e/attachment-0003.html>