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

[Razvan Dragomirescu]

Hello Ivan,

Breaking existing (possibly automated) systems is a _very good reason_ IMHO
:). Sure, warn the operators that they're using a legacy system, deprecate
the option but don't disable it.
https://trac.torproject.org/projects/tor/ticket/18054 sounds like a pretty
sane solution btw.

Even if it's no longer officially supported, I think OnionCat in its
current incarnation is a great proof of what could be done with the Tor
network, other than privacy protection. I actually have this listed on one
of my slides for SIM4Things - it's good for the Tor network, shows it can
be used for a variety of things while putting very little stress on the
network components. Very little traffic, potentially large PR impact (in a
good way :) ).

Razvan

On Tue, Sep 13, 2016 at 1:29 AM, Ivan Markin <twim at riseup.net> 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).
>
> --
> Ivan Markin
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160913/fb6b6917/attachment.html>