Re: [tor-dev] "old style" hidden services after Prop224

I fully agree with the security points, I was just arguing for keeping the _option_ to list a v2 service for a longer time (possibly forever). Let's not make assumptions for the service operators - ok, make them enable the option explicitly, have them do it at compile time if you want to (like Tor2Web) but don't remove it just because you think the alternative is better. Some services (like mine) are not worthy targets for a LEA (unless they're interested in hacking your fridge), Tor is interesting to us because of its NAT traversal capabilities and cryptographic service authentication.

Don't assume that all users have the same goals and they are all fighting well funded or state-level attackers. Another option to be honest would be for us to just fork Tor at the time v2 services are removed altogether and spin a few directory authorities of our own and a few relays around the world (we send very little traffic) and call it a day. Tor can continue onwards with the v3-only services while our Tor fork would be happily using v2, separate from the main network (and less subject to attacks from well funded attackers and DDOS operators interested in revealing activists' identities and not in finding out that you're out of cheese in your fridge). I think there's potential in making a simpler, slightly less secure version of Tor but with significantly improved user experience.

Oh, and no, I wasn't planning on having the Onion Balance and OnionCat devs fix bugs for us :). I just didn't want to duplicate effort, so if they have a plan to adapt their tools to v3, I'd rather wait for their solution than do a half-baked one of our own.

Razvan

On Tue, Sep 13, 2016 at 10:31 PM, s7r <s7r@xxxxxxxxxx> wrote:

On 9/13/2016 6:13 PM, Razvan Dragomirescu wrote:
> I disagree with your approach, for comparison's sake, let's say v2 is
> IPv4 and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and
> still is to this day, although IPv6 is arguably a much better solution
> in a lot of areas). Expecting _everyone_ to just switch to IPv6 or get
> cut off is a bit of a pipe dream.
>

Your analogy with IPv4 and IPv6 is unacceptable. IPv6 exists not because
IPv4 isn't secure, but because the address space got filled up (internet
grew). Of course it has some improvements compared to IPv4 but we cannot
say IPv4 has questionable security. I don't think we can speak about
security in IP context anyway since there are other protocols where this
happens (BGP,TCP etc.). And they do exist in parallel with perspective
to migrate to IPv6 entirely in the future (obviously v2 and v3 hidden
services will have a migration period also, just not so large because we
aren't talking about the entire internet here).

> Tor hidden services are a bit "special" because it's hard to poll their
> owners on their intentions. Some hidden service operators have gone to
> great lengths to advertise their .onion URLs (v2-style), some have even
> generated vanity addresses (like Facebook). Forcing a switch to v3 at
> some point presents a very interesting opportunity for phishing because
> suddenly a service known and trusted at some address (as opaque as it
> is) would need to move to an even more opaque address, with no way to
> determine if the two are really related, run by the same operator, etc.
> If I were a LE agency, I would immediately grab v3 hidden services,
> proxy content to existing v2 services and advertise my v3 URL
> everywhere, then happily monitor traffic.
>

I am not sure what you mean by grabbing v3 hidden services (generating
random ed25519 keys?) and how exactly you are going to proxy anything to
the v2 hidden service without access to v2's private key? But regardless
of how you have in mind to do this, your points are wrong.

Maintaining v2 services just because operators advertised the v2 onion
url style is not an argument. RSA1024 will be easily factored in coming
years. We have strong reasons to believe factoring RSA1024 at current
moment is not impractical if the target is worth it enough. So, if we
allow v2 services forever, we increase the chances for a LE to hijack v2
hidden services by factoring their private keys - this risk is bigger
than what you are describing. For the second part, there are plenty ways
to prove a v2 hidden service is tied to a v3 one, given you control v2's
private key. It provides exactly the same level of cryptographic
certification.

> All I'm saying is don't remove the v2 services, even if you choose to no
> longer support them. Some operators (like my company) may choose to
> continue to patch the v2 areas if required and release the patches to
> the community at large. Forcing us out altogether would make us drop Tor
> and start using an alternative network or expending the additional
> effort to make our services network-agnostic (so no more good PR for Tor).
>

This doesn't sound good. Would your company ship to its users code that
you do not support yourself, but relying on third parties to do so?
Relying on a third party company for patches doesn't sound comfortable
to me (with all due respect, I am sure your company is able to do it
without problems, I just don't think it's professional this way). Rather
than trying to spend time to code patches for the old v2 code why not
spend that time and make your services compatible with v3 hidden
services? OnionBalance and OnionCat will find ways to work with v3
hidden services.

> Ivan was right, moving to v3 would be, at least for my project,
> extremely complex and unwieldy. Ed25519 is not supported by any
> smartcards I know (but can be "hacked" by manually defining Curve25519
> params and converting back and forth). But then we'd have to modify the
> service re-registration (or wait for OnionBalance to do it), then add
> another layer for OnionCat-like lookups, etc. It would be far easier to
> just drop the Tor dependency at that point or centralize it a bit more.
>
> Just my 2 cents, if any hidden service operators wish to chime in, feel
> free to do so. After all, it's us (them? :) ) that will have to make the
> changes to their services.
>

Not only clients. Also, the relays -- hidden service directories -- for
example I don't want to host v2 descriptors on my relays after prop 224
is implemented.

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev