[cabfpub] Ballot 144 - Validation rules for .onion names

[Erwann Abalea]

Bonjour Gerv,

Le 19/02/2015 11:11, Gervase Markham a écrit :
> Hi Erwann,
>
> On 18/02/15 19:07, Erwann Abalea wrote:
>> OpenTrust votes NO.
>  From reading your objections: does this mean you would be in favour
> after the Tor folk move to longer hashes and SHA-256?

Longer hashes may not be necessary, we lived with a 2^80 theoretical 
effort (collision resistance of a perfect hash function) for a while, 
and recently deprecated SHA1.
But what was really deprecated? SHA1 in itself because it's old, despite 
its 2^160 resistance for intermediate certificates and CRLs? The idea of 
a 2^80 collision resistance? The latest estimated 2^61 collision 
resistance of SHA1?
There was a reason to deprecate SHA1, there are consequences (we all 
heard of them and decided to drop legacy software, for good), there's a 
design behind our choices (or there should be). How does this truncated 
SHA1 fit this design?

The other technical objection is that Tor is *full* of keys, and the 
vast majority of them are 1024 bits RSA keys. Some keys are ECC 
Curve25519 ones, but I don't know if they're used for signature or key 
exchange purpose.
There are keys used to generate names, keys used to encrypt data 
exchanged between cells, keys used to sign distributed data, keys used 
to sign descriptor informations published by services, keys used to 
setup rendez-vous tokens to access hidden services, and maybe others.
Keys smaller than 2048 bits are Evil(tm). It's written in stone, we 
track public 1024bits certificates and sue the CAs who produced them, we 
don't like DNSSEC partly because it's also full of 1024 bits keys. 
That's good, I'm fine with it.


I'm not opposed to embrace Tor or any other similar security thing in 
CABForum's definition of a TLS certificate, but I'd like to be sure that 
we all know what is being introduced, the security consequences and 
guarantees of what we're doing. I really like Tor. But understanding Tor 
is hard, and I wouldn't be surprised if a non negligible number of the 
"abstain" votes was caused by this complexity.

>>    * the final goal of this ballot is to allow a Tor user to access a non
>>      hidden service using a hidden service name. Such a user can
>>      *already* access to the public facing classical version of this
>>      service, using its public name.
> Yes; however, people in the middle can both tell that the user is
> accessing the site, and can block their access.

Tor is supposedly targeted for this situation. The exit node knows that 
someone wants to access the site and block it, the entry node knows that 
this specific user wants to access something and block it, but not both. 
In theory.

 From my understanding, accessing a Tor hidden service involves a longer 
path (3 nodes between the user and a rendezvous point, 3 nodes from this 
rendezvous point and the service), provides end-to-end encryption, and 
self-authentication. That's good. Does it solve the anonymity problem? 
Yes, for a hidden service. How does it work for a mixed 
hidden/non-hidden service?

-- 
Erwann ABALEA