Hello George,
Inline comments:
> 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:
>
> d) Should we introduce the concept of stealth auth again?
>
>IIUC the current prop224 client auth solutions are not providing all
>the security properties that stealth auth did. Specifically, if Alice
>is an ex-authorized-client of a hidden service and she got revoked,
>she can still fetch the descriptor of a hidden service and hence
>learn the uptime/presense of the HS. IIUC, with stealth auth this was
>not previously possible.
>
I also share David's feeling here, presence hiding is not so critical
and I am not sure if its worth its engineering and additional code
costs. We can add this feature any time after deployment anyway because
there are many questions and we need some stats and to analyze user
demands in order to take the right decision here. Freezing this specific
feature until further analysis shouldn't be a problem.
>> 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).
>
Agreed.
> ---
>
> WRT protocol, I guess the idea here is that if client auth is enabled,
> then we add some client authorization fields in the top of the encrypted
> section of the descriptor, that can be used to find the client-auth
> descriptor encryption key. Then we add another client-auth-encrypted
> blob inside the encrypted part, which contains the intro points etc. and
> is encrypted using the descriptor encryption key found above.
>
> So the first layer is encrypted using the onion address, and the second
> layer is encrypted using the client auth descriptor key. This won't be
> too hard to implement, but it's also different from what's currently
> coded in #17238.
>
> Do people feel OK with this?
>
Yes, sounds good.
> Also, what should happen if client auth is not used? Should we fall back
> to the current descriptor format, or should we fake authorized clients
> and add a fake client-auth-encrypted-blob for uniformity? Feedback is
> welcome here, and I think the main issue here is engineering time and
> reuse of the current code.
>
> ---
>
I say Yes with capital letter here. We should make as many descriptors
as we can look alike as we can. If client auth is not used, that
descriptor should contain N fake clients (given we choose a reasonable N
that will result in an reasonable average size for descriptors network
wide).
> Now WRT security, even if we do the double-encryption thing, and we
> consider an HSDir adversary that knows the onion address but is not an
> authorized client,we still need to add fake clients, otherwise that
> adversary will know the exact number of authorized clients. So fake
> clients will probably need to be introduced anyhow.
>
Of course, fake clients will patch this problem in a good way - an
adversary that only knows the onion address but its not an authorized
client will not have an _exact_ number of authorized clients no matter
what. And the
