[tor-dev] Revisiting prop224 client authorization

Fri Oct 14 15:40:03 UTC 2016

On 11 Oct (16:58:43), George Kadianakis wrote:
> Hello,

Hi!

Thanks for this George!

> 
> 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?

Personally, I would really like to be able to hide the fact that a service is
using client authorization. Both could hide that but not that trivially.

I would pick double encryption for the simple fact that I really want to us to
expose as little as we can in the plaintext section. Also, it seems to me that
we could increase our chances of fuck up with this "fake client-auth-desc-key
blob" situation for service without client auth?..

An other thing here, I have this feeling that client authorization might
always leak unless we set a maximum number of clients and pad up to that
value. I mean, how much do we pad in for a non-client auth service descriptor?
I guess our ultimate goal would be to make all descriptors look a like in
terms of size? (Except for extra IPs...)

The other thing I which we could fix if we pick double encryption is "if I
know the .onion then I can know how many clients are authorized" but that's a
thougher one and might need us to fake client auth in the encrypted section as
well...

So we should try to answer this question: Do we care about the increasing size
of the descriptor considerably from what we have now? I could see a concern on
mobile or even the horrible world of IoT (which uses cell's networks a lot in
the end.)

To give an idea, how we implemented 224 so far, a default descriptor (with 3
non-legacy IPs and no client auth) is 3153 bytes. Every new IPs adds ~870
bytes (this can vary a bit depending if IPv6). Adding a legacy IP (RSA keys),
we are are ~1215 extra bytes (again vary because IPv6).

I tend to say yes to increasing descriptor size if it's offer more security. I
mean, <10k bytes is pretty small also on todays network I guess?...

> 
>    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?

I would definitely not NACK with a error code that says "authorization
failure" as this gives out a new "oracle" to anyone out there to poke the
service.

However, I would assume that most of the NACK would come from bad
authorization because establishing an INTRO with the service is usually not
something that fails often...

So I'm hesitant here to do so as it would be very useful for only a specific
use case of HS that is client auth. And when I say specific is that I assume
blindly that most HS out there don't use client auth much... I might be very
wrong!

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

In this case, revoking a client would mean changing the fetch key for _all_
clients as we can't really make one per-client else the descriptor size goes
++! but maybe we should think about it! Would be kind of a list of "fetch key"
that are acceptable instead of a single one.

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

Right... it would be something extra you put in the .onion address I guess?
Hey look, _bigger_ addresses :D. Or an extra string next to the .onion that
Ricochet would have to generate as part of the Ricochet ID.

Globally, I'm not against this idea except if it's one single fetch key for
everyone, it's kind of annoying and a compromised client makes it pointless
as the service can't revoke it :S ...

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

Yes, I would really like to hide it as much as we can. HS circuits already
have a distinctive patterns, would be good to avoid leaking information on
which HS is being used on that HS circuit... :)

Thanks!
David

> 
> 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 :)
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161014/84020d2a/attachment.sig>