[tor-dev] Revisiting prop224 client authorization

[s7r]

Hi David,

David Goulet wrote:
> 
> Personally, I would really like to be able to hide the fact that a service is
> using client authorization. Both could hide that but not that trivially.
> 
> I would pick double encryption for the simple fact that I really want to us to
> expose as little as we can in the plaintext section. Also, it seems to me that
> we could increase our chances of fuck up with this "fake client-auth-desc-key
> blob" situation for service without client auth?..
> 
> An other thing here, I have this feeling that client authorization might
> always leak unless we set a maximum number of clients and pad up to that
> value. I mean, how much do we pad in for a non-client auth service descriptor?
> I guess our ultimate goal would be to make all descriptors look a like in
> terms of size? (Except for extra IPs...)
> 
> The other thing I which we could fix if we pick double encryption is "if I
> know the .onion then I can know how many clients are authorized" but that's a
> thougher one and might need us to fake client auth in the encrypted section as
> well...
> 
> So we should try to answer this question: Do we care about the increasing size
> of the descriptor considerably from what we have now? I could see a concern on
> mobile or even the horrible world of IoT (which uses cell's networks a lot in
> the end.)
> 
> To give an idea, how we implemented 224 so far, a default descriptor (with 3
> non-legacy IPs and no client auth) is 3153 bytes. Every new IPs adds ~870
> bytes (this can vary a bit depending if IPv6). Adding a legacy IP (RSA keys),
> we are are ~1215 extra bytes (again vary because IPv6).
> 
> I tend to say yes to increasing descriptor size if it's offer more security. I
> mean, <10k bytes is pretty small also on todays network I guess?...
> 

Hey, very clever how you thought about this. I wanted to say no, don't
limit the max number of clients can be authorized on a HS, but a
descriptor has to have some hard limit anyway (I guess it has one, if
not it should). So, bottom of the line, the theoretical possible number
of authorized clients is already limited by the max descriptor size.

I think it's simpler if we think towards making the majority of
descriptors look alike (in terms of size) as opposite to making each and
every one look alike (in terms of size) because this means we need to
pad up to the hard limit in all cases. Considering the introduction
points, which can be from 3 to 20 and add to that how many clients we
have authorized this creates very different possible descriptor sizes.

What we should do is come up with a fair number of authorized clients
which is in most cases not exceeded (hard to come up with accurate stats
for this), and pad up to that with dummy authorized clients for both
auth enabled hidden services with less authorized clients than the
so-called 'default' number and non-auth hidden services.

This could also partially solve "if I know the .onion I know how may
clients are authorized". Only the auth-enabled HSes who have more
authorized clients than the so-called 'default' number will leak this
this popularity info, but it should be no worse than the current stage
anyway. This is better because the majority of auth-enabled hidden
services are assumed to be under this limit so you can't tell their
exact number of authorized clients because you don't know how many of
them are dummy clients.

Hardest part here is picking the right numbers:

MAX ALLOWED DESCRIPTOR SIZE (descriptor version will be useful in case
we decide to change this limit in the future)
DEFAULT NUMBER OF AUTHORIZED CLIENTS - let's say 100 (this is not based
on any analysis, just what came into my mind - probably not a good
number). I am inclined to make this number as high as we can considering
mobile clients and/or small bandwidth clients.

In this case a HS with 1 authorized client will have in its descriptor:
1 real authorized client
99 dummy authorized clients which do not exit but nobody can tell

A HS with 2 authorized clients will have the real:dummy client ratio
2:98, and so on.

When new authorized clients are added, the dummy slots will be occupied
first, if previous authorized clients weren't revoked/deleted.

A non-auth HS will have 100 dummy authorized clients (??? or 99 and
global non-auth anyclient ???).

If we can't make all descriptors perfectly equal in terms of size (not
because it's technically impossible, but because of the costs) at least
making the very vast majority of them look alike is one step forward.

-------------- 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/20161014/a169b1a0/attachment.sig>