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

[Alex Xu <alex_y_xu@xxxxxxxx>]

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.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev