[cabfpub] Ballot 144 -.onion domains

[Jeremy Rowley]

Actually, this illustrates exactly why EV is being used for these.  Someone might be able to generate a name that looks similar to the facebook onion name.  Without EV, you couldn’t convey which is the actual onion service run by facebook, making it easier to conduct phishing attacks.  All onion names are meaningful in that they tie the service to a particular key. With EV, you have a way to tie the key directly to an existing organization.




From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com]
Sent: Thursday, February 12, 2015 7:33 PM
To: Gervase Markham; Jeremy Rowley; Ben Wilson
Cc: CABFPub (public at cabforum.org)
Subject: RE: [cabfpub] Ballot 144 -.onion domains


Gerv, you made an interesting point below in response to my message:



[Kirk] If Facebook can reverse engineer to get that .onion domain, couldn’t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain?



[Gerv] No. What Facebook did was generate a lot of hashes starting "facebook", reviewed them, picked the one they liked best and then invented a "reason" for why it's that one: "Facebook's Core WWW Infrastructure".



However, generating a second one which exactly matched the name Facebook picked is a much harder process.



Fair enough.  But if Facebook can engineer *multiple* public keys that hash so the first 8 characters of ALL of them are “facebook”, I’m guessing its not that hard and a hacker could do the same thing (or get the first 5 as yahoo, the first 6 as google, or the first 8 as microsoft).  After that, the rest of the characters could be random or meaningful, but the potential harm (trickery in the domain name) is already done.



Under the ballot, CAs have no obligation to scan or verify a *meaningful* .onion domain and look for phishing or fraud attempts.  I was under the impression that .onion domain names were ALWAYS 12 random characters (which avoids fraud); now I see that people who want a specific .onion name can arguably game the system to get a meaningful name that they want (and it might not even be their own name – gervmarkham1 for example).



Under BR 9.2.4g, CAs are not permitted to issue certs with unverified names in the OU field:


The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 11.2 and the Certificate also contains subject:organizationName, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 11.2.



Of course, the OU field is not very important because it’s almost never visible to users.



In contrast, a .onion domain name will be displayed to Tor users, and could cause confusion.  Should we require CAs to follow the rules of BR 9.2.4g so that .onion domains that include meaningful names are verified?  Or better yet, not allow .onion domains to be meaningful (require them to be random only)?



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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150213/517e3bd0/attachment-0003.html>