[tor-dev] v2 to v3 onion service transition (was: "old style" hidden services after Prop224)

[David Goulet]

On 13 Sep (21:45:00), Ivan Markin wrote:
> Forking this thread to discuss onion service transition path.
> 
> David Goulet:
> > 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.

Ok Ok. I'm going to TL;DR; the previous thread here to make sense of what's
down there written by Ivan.

It seems everyone agrees on a transition path from v2 to v3. There was a
debate about if we should kill v2 after some time in favor of _only_ having
v3. Security arguments were raised which was also tied to Tor's mission
statement (thx Lunar!). From the maintaining perspective, it does NOT make
sense to keep v2 over time as 1) it's broken by design and 2) the security of
it is bad (RSA1024 and SHA1 and TAP). The HS subsystem is a very complex one
for which we should keep maintaining only if we have confidence that it's safe
to be used which fails for v2 because of 1) as for starter. So I personally
believe it's Tor's duty to provide a transition path and drop a unsecure
protocol else we litterally put user at risk which is bottom line for me
unacceptable and supersede any other argument about how it's being used in
some stable way (like let's say IoT).

That being said, if someone still doesn't agree, raise your voice with
arguments that haven't been heard yet. If you also want to add more arguments
in favor of dropping v2, you are welcome to do so! :)

One issue raised here by Ivan is a way to cross-certify v2 -> v3 where a
service would like to provide this mechanism for client to confirm they do
have the right v3 address for the great-leaking-platform.onion v2 :).

> 
> We can add arbitrary fields into descriptors. So we can build up kinda
> "aliases". What comes to mind first:
> 
>     Onion Service Operator
>       Publishes v2 descriptor with v3 cross-certification.
>       Publishes somewhere their v3 address and cross-cert*.
>     v2-only client
>       Uses v2 service.
>     v3-compatible client
>       Takes v3 address from a descriptor for requested v2 address.
>       Makes a connection to v3 address that looks like a connection
>       to v2 for the end user. There should be no v3->v2 downgrade
>       option. One-way ticket.
>     v3-only client
>       Uses v3 service.
> 
> Also, there should not be any torrc options, I think. There is no
> behavior to control so there is no need to make this transition even
> more sophisticated.

I think there might be one. An operator should have the choice to
cross-certify a v2 -> v3 linking the two .onion together. I for instance have
lots of .onion that I might not want people to link the v3 to the v2. So I
should have a way to tell Tor to leave my v2 alone during the transition
period.

The thing that worries me about the approach of:
    "Publishes somewhere their v3 address and cross-cert*."

... is the amount of more traffic and complexity we had to the network for
such a thing. I for sure don't want Tor to maintain some sorts of registry
here just for a transition period that ultimately will die. Anyway, Tor
shouldn't have to provide infrastructure for the actual network to work well.

What if the operator has a torrc option that says "Please use this v2 HS and
cross certify it with the v3.". Out of my head (just an example):

    HiddenServiceDir /my/service/one
    HiddenServicePort ...
    HiddenServiceLinkedWithV3 1

    HiddenServiceDir /my/service/two
    HiddenServicePort ...
    HiddenServiceLinkedWithV3 0 /* Would be off by default to avoid linkability. */

Which adds fields to the v3 descriptor including a v2 signing key? in order to
avoid the client to fetch the v2 descriptor. Something I don't like about this
is that we introduce a torrc option _and_ descriptor fields that will get
obsolete when v2 is dropped... and that only informed power user will be able
to understand what the hell is going on (but that we can maybe fix with good
documentation, blog post and good practices guide).

We should also consider if it's really Tor's job to do this. Maybe it's OK to
leave this job to the operators to deal with the v2 <-> v3 advertisement by
themselves?

My guts tell me that I would like to have v3 tied to v2 as little as possible
really but I also want current .onion operator to be able to provide maximum
security for their users _especially_ when a .onion is very difficult to give
around in some harsh political context.

Thoughts? Brainstorming time! :)

Cheers!
David

> 
> * There should be a simple tool to generate and verify
> cross-certifications. Like signify(1) from OpenBSD. Or even simpler.
> Probably something that even built into TBB.
> 
> Don't know if such transparent connection thing is secure or not. It
> seems to be as secure as v2 services.
> Thoughts?
> 
> --
> 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/20160914/e04d02ba/attachment.sig>