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

[David Goulet]

On 12 Sep (22:29:00), Ivan Markin wrote:
> Razvan Dragomirescu:
> > Thank you Ivan! I still dont see a very good reason to _replace_ the 
> > current HS system with the one in Prop224 and not run the two in
> > parallel.
> 
> For me it's because it would make overall system more complex and thus
> error-prone and reasonably less secure. Is like using RC4, SHA1, 3DES in
> TLS and be vulnerable downgrade attacks and all kind of stuff like
> Sweet32 and LogJam (export-grade onions, haha).
> 
> > Why not let the client decide what format and security
> > features it wants for its services?
> 
> It's like dealing with plethora of ciphers and hashes in GnuPG:
> 
> https://moxie.org/blog/gpg-and-me/:
> > It’s up to the user whether the underlying cipher is SERPENT or IDEA
> > or TwoFish. The GnuPG man page is over sixteen thousand words long;
> > for comparison, the novel Fahrenheit 451 is only 40k words.
> 
> When system is complex in that way someone is going make huge
> mistake(s). If crypto is bad, just put it into museum.
> 
> So I don't see _any_ reason to manage outdated and less secure system
> while we have a better option (if we already deployed it).

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

> 
> --
> Ivan Markin
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160913/f67bfc74/attachment.sig>