[tor-dev] Revisiting prop224 client authorization

Wed Nov 2 17:45:03 UTC 2016

On 01 Nov (13:32:13), George Kadianakis wrote:
> David Goulet <dgoulet at ev0ke.net> writes:
> 
> > [ text/plain ]
> > On 17 Oct (13:35:24), George Kadianakis wrote:
> >> George Kadianakis <desnacked at riseup.net> writes:
> >> 
> >> > [ text/plain ]
> >> > Hello,
> >> >
> >> > we've reached the point in prop224 development where we need to pin down
> >> > the precise cell formats, so that we can start implementing them. HS
> >> > client authorization has been one of those areas that are not yet
> >> > finalized and are still influencing cell format.
> >> >
> >> > Here are some topics based on special's old notes, plus some further
> >> > recent discussion with David and Yawning.
> >> >
> >> 
> >> Hello again,
> >> 
> >> I read the feedback on the thread and thought some more about this. Here
> >> are some thoughts based on received feedback. A torspec branch coming
> >> soon if people agree with my points below.
> >> 
> >> I'd also like to introduce a new topic of discussion here:
> >>
> >> <snip>
> >> 
> >> > a) I think the most important problem here is that the authorization-key logic
> >> >    in the current prop224 is very suboptimal. Specifically, prop224 uses a
> >> >    global authorization-key to ensure that descriptors are only read by
> >> >    authorized clients. However, since that key is global, if we ever want to
> >> >    revoke a single client we need to change the keys for all clients. The
> >> >    current rend-spec.txt does not suffer from this issue, hence I adapted the
> >> >    current technique to prop224.
> >> >
> >> >    Please see my torspec branch `prop224_client_auth` for the proposed changes:
> >> >    https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth
> >> >
> >> >    Some further questions here:
> >> >
> >> >    i) Should we fake the client-auth-desc-key blob in case client authorization
> >> >       is not enabled? Otherwise, we leak to the HSDir whether client auth is
> >> >       enabled. The drawback here is the desc size increase (by about 330 bytes).
> >> >
> >> >       Alternatively, we can try to put it in the encrypted part of the
> >> >       descriptor. So that we require subcredential knowledge to access the
> >> >       encrypted part, and then client_auth_cookie knowledge to get the
> >> >       encryption key to decrypt the intro points etc. I feel that this
> >> >       double-encryption design might be too annoying to implement, but perhaps
> >> >       it's worth it?
> >> >
> >> 
> >> Seems like people preferred the double-encryption idea here, so that we
> >> reveal the least amount of information possible in the plaintext part of
> >> the desc.
> >> 
> >> I think this is a reasonable point since if we put the auth keys in the
> >> plaintext part of the descriptor, and we always pad (or fake clients) up
> >> to N authorized clients, it will be obvious to an HSDir if a hidden
> >> service has more than N authorized clients (since we will need to fake
> >> 2*N clients then).
> >> 
> 
> Hello,
> 
> I worked some more on the descriptor part of client authorization and
> prepared a torspec patch. You can find it at `prop224_client_auth_2` in
> my repo:
>    https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224_client_auth_2&id=a85ffa341cc6c493ad031972f466a6dd5d8510e2
> 
> Based on received feedback, I went with the double-layer encryption
> style, where the first layer is encrypted using the HS pubkey and the
> second layer is encrypted using the descriptor cookie. Inside the first
> layer plaintext is the information for authorized clients to derive the
> descriptor cookie.
> 
> I also included the padding suggestions from my previous post that
> should help with hiding the number of client auths.
> 
> I'd like feedback on the following:
>     
> a) Do you like the descriptor format and logic? Can we make it nicer or
>    easier to implement? 

This line in the superencrypted section:

     "auth-client" SP iv SP client-id SP encrypted-cookie

... all three values will be raw bytes as far as I can tell. I'm fine with
bytes in the descriptor (like we do know for v2) but mixing "text param" with
"binary param" might not be ideal. If we want a human readable representation,
I would go with base64 encoding those or if not, full binary.

I like the human readable personally as it's so much easier to debug. As we
stated before, size is not that of an issue and going from binary to base64
won't create huge strings at all... Downside, we have to parse more strings!
:P but we do that _HEAVILY_ anyway with descriptors so...

> 
> b) Do you like the proposal format? Is it messy and/or hard to
>    understand? Ideas on how can it be improved?
> 
>    I think we have reached the point where every subsystem of prop224 is
>    complex enough to warrant its own proposal, but I'm resisting the
>    urge to dig into this rabbithole right now.

We could indeed split but I think it's fine for now. Not sure it's worth the
extra work for now unless anyone thinks so?

> 
> c) Is the descriptor cookie encryption format good enough Namely:
>      encrypted_cookie = STREAM(iv, client_auth_cookie) XOR descriptor_cookie
> 
> d) Current changes: I changed "authentication-required" to
>    "intro-auth-required" in the descriptor, to make it more clear its
>    about introduction-layer authentication.
> 
> Feedback on the patch and the above points is very much welcome!

Extra stuff:

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

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

Cheers!
David

> 
> BTW, I'm not done with this thread yet, there are still some more points
> that need to be handled wrt client authorization. But this spec patch is
> the most important and lengthiest of them all, so let's get it out of
> the way first.
> 
> Thanks!
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161102/a955a071/attachment.sig>