Alex Xu <alex_y...@yahoo.ca> writes: > Quoting George Kadianakis (2018-07-11 19:26:06), as excerpted >> Michael Rogers <mich...@briarproject.org> writes: >> >> > On 11/07/18 14:22, George Kadianakis wrote: >> >> Michael Rogers <mich...@briarproject.org> 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev