[tor-dev] Revisiting prop224 client authorization

[s7r]

I am very happy with the torspec patch.

Not quoting entirely, only want to add something wrt randomizing the
value for fake clients based on David's and teor's comments:

David Goulet wrote:
[SNIP]
> 
> - I think "superencrypted" -> "super-encrypted" would be nicer as everything
>   in the descriptor as that separation of word. Or even "client-encrypted" if
>   we want to add extra semantic. No strong opinion apart from the "-" :).
> 

I prefer super-encrypted vs. client-encrypted.

> - [XXX consider randomization of the value 16]
> 
>   If it's fixed, we basically create bucket so a client can know that there
>   are 0-16 clients or 16-32 clients and so on.
> 
>   If we randomize that value and let's say it's 7 then we have bucket of 7. If
>   that value is randomized _every_ new descriptor, we create multiple size of
>   buckets but over time someone could deduce (maybe) the low bound of clients
>   by observing all random values and thus assume there are 0-<low bound>.
> 
>   I'm uncertain here what's best but seems that in any case, bucketing is
>   happening as we pad with fake "auth-client". So I would assume here, out of
>   my head to be safe, that we might want _all_ services to kind of look the
>   same thus a fixed value would make sense following that train of thought.
> 
> I'm liking the rest here! We'll have to think also on some padding in the
> INTRODUCE1 cell to avoid leaking client auth is being used.
> 

This is true, we create buckets no matter what, but I think it's better
if one has to watch a hidden service for a lot more time to determine
the probable number rather than being able to tell from the first
descriptor that there are 0-16 clients, 16-32 clients and so on.

I fully agree that randomizing _every_ new descriptor does not help and
probably in short time someone could deduce a possible number, but I am
slightly uncomfortable with a global fixed value for this. One more
idea, if it's not helpful we can just go ahead with a fixed value of 16.

I think it's better if we pick a random number between 8 and 32 fake
clients and remember the picked value so it will be used for every new
descriptor until something in our setup changes or enough time has
passed. In order to know when to reset it, we save it (in our state)
along with:
1. The number of real authorized clients when the random value was picked.
2. Timestamp when the random value was picked + an end of life for the
random value.

We reset the random value of fake authorized clients and also its end of
life when:

a) number of real authorized clients in torrc changes from what we have
in our state.
b) end of life for the random value is reached. End of life will be
timestamp + a random period between 30 and 90 days.
c) obvious case when Tor is re-installed and old state is lost.

We call this function on every HUP and (re)start. We can tune the
numbers 8 - 32 and period 30 - 90 days as you like.

This way there are a lot of buckets and significantly more time needed
for an observer to deduce a probable number. It is quite possible one
can never deduce a "probable enough" number.

We combine this with faking extra if needed in the encrypted portion to
the next multiple of 10k bytes.

It's true that it won't help if the hidden service operator changes the
number of authorized clients every hour for a long period but in
practice this doesn't happen - number of authorized clients changes
rarely. And even in this scenario it still makes things a lot more
confusing.

Compared to other parts of prop 224, this is easy to code and should be
worth the effort. What do you think?

Thanks a lot for considering all my previous points.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161103/ad6ec383/attachment.sig>