[tor-dev] Revisiting prop224 client authorization

[George Kadianakis]

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?

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

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

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?

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

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

As you can see I have mainly worked on point (a) which I consider the
most urgent. I welcome feedback on all points, so that we move forward
with the design here.

Thanks :)