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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev