[cabfpub] Ballot 144 -.onion domains

Fri Feb 13 16:28:29 UTC 2015

Thanks, Gerv – but if it wasn’t too hard for Facebook to generate multiple “facebook” .onion domains (presumably using automated methods), I’m not convinced it would be hard for hackers.  And I’m still troubled that the .onion plan allows multiple customers to obtain the same .onion domain (meaning there could be multiple certs for the same .onion domain that belong to different subjects).

I have to circle back to “Why are we doing this?”

•                    Tor users want to visit websites anonymously.  [That sounds like something CAs should support if possible]

•                    Website owners do *not* want anonymity – in fact, just the opposite.  They want EV certs with their identity information included that will work for Tor users.

•                    For some reason, regular TLD certs (like .com certs) won’t work after Tor users go through the Tor blender.  [Does anyone know why that is the case?]

•                    But for some reason, Internal Name .onion certs *do* work for Tor users after they go through the Tor blender.  [Does anyone know why this is so?]

•                    Tor does not want to apply for .onion as a TLD, and does not want to be the registrar for .onion [Why not?  That would solve everything by making .onion a TLD, so all the current CA rules could apply.  And remember, website users are not looking for anonymity in their certs – they want EV certs with their identity displayed prominently in the browsers.]

•                    The Tor process for assigning .onion domains does not require domains to be unique.

Why won’t regular TLD certs work in Tor?  Why do .onion Internal Name certs work in Tor?  Could Tor fix this discrepancy so we don’t have to continue allowing Internal Name certs for the .onion case?

If two or more website owners receive the same .onion domain (either by accident, or by design of some of the website owners who choose what their .onion domain will be, like Facebook did), how does Tor resolve this clash?  Where does it send users?

I really don’t understand why we have to create an exception to the rules to accommodate this case.

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Friday, February 13, 2015 1:53 AM
To: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com)
Cc: CABFPub (public at cabforum.org)
Subject: Re: [cabfpub] Ballot 144 -.onion domains

Hi Kirk,

On 13/02/15 02:33, kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> wrote:

> 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.

.onion names represent 80 bits of data (half of the 160 bits of a SHA-1

hash) and are 16 characters, so each character represents 5 bits. This means that to fix the first character would require generating about 32

(2 ^ 5) keys. Not many. But to fix the first two characters would require 32 ^ 2 = 1024 keys. Each additional character you want to fix makes the job 32 times harder.

Therefore, getting even one key where the first 8 hash characters are "facebook" requires approx. 1 x 10^12 keys to be generated (that's 100,000,000,000). Facebook has a lot of computing power, so they could do this. This is not out of the reach of others, but would be expensive.

I'm not sure a phisher would consider this the most cost-effective method of phishing.

> Under the ballot, CAs have no obligation to scan or verify a

> **meaningful** .onion domain and look for phishing or fraud attempts.

Do they have such an obligation for normal domain names?

If so, why does that obligation not extend to .onion names?

> 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).

The longer the required "meaningful" portion is, the harder it is to find a name beginning with it. As I said, each extra character you want makes it 32 times harder.

So getting an 8-character prefix ("facebook") requires approx. 1 x 10^12 keys to be generated. Getting an 11 character prefix ("gervmarkham") requires 3.6 x 10^16 - i.e. it's 32,678 times harder. 11 characters would have been out of the reach of even Facebook.

> 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)?

I think the idea of requiring "randomness" would not be any better.

Let's say we required Facebook to be:

5jdgiu3sn4j2lkqq.onion.

It would be equally as easy for someone to generate a key matching the first 8 letters of this as it is for someone to generate one matching the word "facebook". So for the same effort as above, I could generate:

5jdgiu3sya3mldpz.onion

I'm not convinced that a user is going to recognise the difference between those two better than the difference between two strings starting "facebook".

This is fundamentally why the proposal is that onion names be EV only - because looking at the domain name is not a good way of determining the owner, whether it's random or mnemonic.

Gerv

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
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.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150213/ce6a71ba/attachment-0003.html>