[cabfpub] Ballot 144 -.onion domains

[Jeremy Rowley]

One caveat is that another ballot is not required if the IESG officially recognizes .onion a reserved name.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Thursday, February 12, 2015 2:02 PM
To: kirk_hall at trendmicro.com
Cc: Jeremy Rowley; CABFPub; Ben Wilson
Subject: Re: [cabfpub] Ballot 144 -.onion domains


On Feb 12, 2015 12:43 PM, "kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>" <kirk_hall at trendmicro.com<mailto: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<mailto: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/20150213/67458ded/attachment-0003.html>