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

[s7r]

On 9/13/2016 3:27 PM, David Goulet wrote:
[SNIP]
> Hello!
> 
> So I 100% share Ivan's concerns. The Hidden Service subsytem of Tor is quite
> complex, lots of pieces need to be glued together and prop224 will add a lot
> of new code (in the 10 of thousand+).
> 
> We decided a while back to have the two protocols living side by side at first
> that is current system (v2) and next gen (v3). Relays will need to support v2
> for a while after v3 is release because well not everybody updates their tor
> to the latest. Lots of people have current .onion for which they need a
> transition to the new generation which includes telling their users about the
> new 52 character one and SSL certs and so on...
> 
> The question arise now. Someone running a .onion upgrades her tor that
> supports v3, should we allow v2 to continue running or transition it to v3 or
> make them both happy together...? We haven't discuss this in depth and thus we
> need to come to a decision before we end up implementating this (which is
> _soon_). I personally could think that we probably want to offer a transition
> path and thus have maybe a torrc option that controls that behavior meaning
> allowing v2 for which we enable by default at first and then a subsequent Tor
> release will disable it so the user would have to explicitely set it to
> continue running v2 .onion and then finally rip off v2 entirely in an other
> release thus offering a deprecation path.
> 
> However, we are clear that every _new_ service will be v3 and never again v2
> unless it already exists that is we can find a RSA private key (considering we
> do the above of course). And considering both will be supported for a while,
> we'll have to maintain v2 security wise but all new features will go in v3.
> 
> Let's discuss it and together we can come up with a good plan! :)
> 
> Thanks!
> David
> 

v2= old-style (RSA1024) hidden services
v3= prop 224 (ed25519) hidden services

I agree with David - it will be problematic to maintain support for both
v2 and v3, unlimited in the future. It's clear that we need to offer a
reasonable transition period, so everyone can upgrade and move their
customers/user bases to the new hidden services, but this doesn't mean
v2 should work forever.

v2 hidden services already provide questionable security (from crypto
point of view) and in the future things will only get worse for v2. I
agree that there are a lot of third party tools working with v2 hidden
services (OnionCat, OnionBalance) -  these all need to be improved to
support prop 224 hidden services.

Considerable resources are spent on v3 hidden services. They are better
vs v2 from all points of view, I don't think keeping the v2 code and
therefor allowing additional attack surface + creating the task to
maintain this old code (v2) in future releases is worth it. This is how
things work in software, if something gets upgraded everything upper
layer should upgrade as well. Keeping parallel older versions to allow a
feature of non-mandatory upgrades is not solid reason for us to do it.

Also, we need to move with Prop 245 (deprecate TAP handshake entirely)
and the v2 hidden service code is the blocker for this.

So, my opinion is to deprecate v2 entirely after a sane and reasonable
transition period.  Apologies to whom this will create headaches -
technologically everything can be adjusted to v3 hidden services, it's
just some work required -- it's not going to be fun but it's the clean
way for the longer term future.

-------------- 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/1fbe0dcb/attachment.sig>