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@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev