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

[s7r]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160913/da0872e2/attachment.sig>