Re: [tor-dev] Alternative directory format for v3 client auth

[George Kadianakis <desnacked@xxxxxxxxxx>]

Alex Xu <alex_y_xu@xxxxxxxx> writes:

> Quoting George Kadianakis (2018-07-11 19:26:06), as excerpted
>> Michael Rogers <michael@xxxxxxxxxxxxxxxx> writes:
>> 
>> > On 11/07/18 14:22, George Kadianakis wrote:
>> >> Michael Rogers <michael@xxxxxxxxxxxxxxxx> writes:
>> >> 
>> > First, Ed25519-based authentication ("intro auth"). Could this be punted
>> > to the application layer, or is there a reason it has to happen at the
>> > Tor layer?
>> >
>> 
>> Yes, it could be stuffed into the application layer. However that could be
>> an argument for everything (including end-to-end encryption of onions).
>> 
>> It might be the case that some application-layer protocols don't allow
>> any sort of pluggable authentication to happen on top of them, or that
>> users wouldn't want to enable them for some reason. Does this feel like
>> an artificial reason to you?
>> 
>> Another positive thing about intro auth is that it allows fine-grained
>> control over authentication, potentially allowing different tiers of
>> users etc.
>
> That might be true, but it's not an argument for intro auth, because
> application-layer authentication offers that too.
>
>> Also see https://lists.torproject.org/pipermail/tor-dev/2018-May/013155.html
>> 
>> > Fourth, what goals does desc auth achieve in the v3 design? If I
>> > understand right, in v2 its major goal was to hide the intro points from
>> > everyone except authorised clients (including HSDirs). In v3 the intro
>> > points are already hidden from anyone who doesn't know the onion address
>> > (including HSDirs), so this goal can be achieved by not revealing the
>> > onion address to anyone except authorised clients.
>> >
>> > I'm probably missing something, but as far as I can see the only other
>> > goal achieved by desc auth is the ability to revoke a client's access
>> > without needing to distribute a new onion address to other clients. This
>> > seems useful. But again, I'd ask whether it could be punted to the
>> > application layer. The only advantage I can see from putting it at the
>> > Tor layer is that the list of intro points is hidden from revoked
>> > clients. Is there a real world use case where that's a big enough
>> > advantage to justify putting all this authorisation machinery at the Tor
>> > layer? Or maybe there are other things this design achieves that I
>> > haven't thought of.
>> >
>> 
>> Yes, you identified the point of desc auth correctly.
>> 
>> Another very important reason to have an authorization system inside
>> Tor, is because it allows only authorized clients to rendezvous (and in
>> general directly interact) with the onion service. That can mitigate all
>> sorts of guard discovery and correlation attacks that could be doable by
>> anyone, and restrict them only to authorized users.
>> 
>> Of course the above is achieved with either desc auth or intro
>> auth. Having both of them does not offer any benefits in this direction.
>
> asn said that a benefit of Tor-level authentication is that users may be
> likely to accidentally reveal their onion service address, e.g. by
> posting screenshots, or copying and pasting the URL, but are less likely
> to accidentally reveal their separate authentication credentials.
>
> I thought of a minor benefit of desc auth: revoked clients are prevented
> entirely from attacking the onion service, e.g. by DDoS.

True. This is actually one of the most useful benefits of client auth
right now: blocking introduction requests from non-authenticated clients
and hence blocking guard discovery or DDoS attacks.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev