David Goulet dgoulet@ev0ke.net writes:
[ text/plain ] On 17 Oct (13:35:24), George Kadianakis wrote:
George Kadianakis desnacked@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_aut...
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_...
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?
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.
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!
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!