David Goulet <dgoulet@xxxxxxxxx> writes:
> [ text/plain ]
> On 17 Oct (13:35:24), George Kadianakis wrote:
>> George Kadianakis <desnacked@xxxxxxxxxx> 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?
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!
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev