> On 14 Sep 2016, at 00:40, s7r wrote:
>
> Also, we need to move with Prop 245 (deprecate TAP handshake entirely)
> and the v2 hidden service code is the blocker for this.
As an aside, if it wasn't for v2 hidden services, we could have removed TAP
entirely in 0.2.9.
Instead,
I agree with both s7r and Lunar here. Just want to add some bits:
> 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
>
I fully agree with the security points, I was just arguing for keeping the
_option_ to list a v2 service for a longer time (possibly forever). Let's
not make assumptions for the service operators - ok, make them enable the
option explicitly, have them do it at compile time if you want to (like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
s7r:
> 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
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
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
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
>
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
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.
Why not let the client decide what format and security features it wants
for its services?
Razvan
On 13 Sep 2016 00:37, "Ivan Markin"
Hi Razvan,
Razvan Dragomirescu:
> I've developed against the current hidden service infrastructure and it
> appears to work like a charm, but I'm a bit worried about Prop224. That
> will break both the OnionBalance-like service re-registration that I'm
> using _and_ the OnionCat HS to IP6
Hello everyone,
I've pretty much completed a proof of concept of my SIM4Things project (an
IP6 overlay for the Internet of Things running on top of Tor with
persistent secure cryptographic identities tied to physical SIM cards).
I've developed against the current hidden service infrastructure and
11 matches
Mail list logo