[tor-dev] Revisiting prop224 client authorization

[teor]

> On 12 Oct 2016, at 07:58, George Kadianakis <desnacked at riseup.net> wrote:
> 
> 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.
> 
> 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?

Double-encryption, because it minimises leakage.
But then the size of the descriptor probabilistically leaks client auth anyway,
because 330 bytes is not that much smaller than the padding to a multiple of
512 bytes.

So do we need all HSs to include either padding or a client auth section?

>   ii) Should we use the descriptor ASCII format to encode all the
>       client-auth-desc-key data? Or is that weird binary format OK?

ASCII? If it's not too hard?
Better to make it readable for people who have to parse and debug it.

>   iii) Should we use a fresh IV for each ENCRYPTED_DESC_COOKIE? rend-spec.txt
>        does not do that, and IIUC that's OK because it uses a fresh key for
>        every encryption (even though the plaintext and IV is the same).

Why not?
Re-using IVs is generally bad practice, even if it works in this case.

> b) Do we want a NACK from the HS for when client authorization fails? Currently
>   the only way for a client to learn that they are not authorized (or that
>   their keys changed or got revoked) is that they never complete the rendezvous.
> 
>   To achieve that we would need a whole new cell (INTRODUCE_SERVICE_NACK) from
>   the hidden service all the way to the client. Worth it?

This is better UI for the client, at the cost of leaking some information about
why authentication failed.

In general, authentication systems try to avoid providing specific information
about why authentication failed. But I'm not sure if that applies in this
specific case.

> c) Another suggestion here by special, is to introduce an additional
>   layer of access control at the HSDir request level, such that HSDirs
>   don't even serve descriptors to clients that do not prove knowledge
>   of a pre-shared fetch key.
> 
>   This way unauthorized clients cannot even learn presense information of
>   hidden services. This might be quite useful for applications like Ricochet,
>   who want to hide their presense from revoked clients.
> 
>   Of course this assumes that the HSDir is honest and will honor the fetch key
>   protocol. However, even if the HSDir is dishonest we are just back to the
>   current security level.
> 
>   We started sketching out a solution in the bottom of these notes:
>     https://people.torproject.org/~asn/hs_notes/client_auth.jpg
>   but the solution is not trivial to implement and we are not sure whether
>   it's worth complicating the protocol further (e.g. we need to design a way
>   for apps like Ricochet to get access to the fetch key).

Why do we need both a fetch key and a client auth key?
Isn't proving that you have a fetch key and a client auth key redundant?

> d) It might be worthwhile padding the encrypted part of INTRODUCE1 to obscure
>   whether client authorization is in place.

Yes.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------------







-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161012/0fb985f0/attachment-0001.sig>