Re: [tor-dev] prop224: What should we do with torrc options?

[teor <teor2345@xxxxxxxxx>]

> On 28 Nov. 2016, at 03:24, David Goulet <dgoulet@xxxxxxxxx> wrote:
> 
> On 27 Nov (00:44:39), Matthew Finkel wrote:
>> On Sat, Nov 26, 2016 at 09:25:44PM +1100, teor wrote:
>>> 
>>>> On 26 Nov. 2016, at 02:25, David Goulet <dgoulet@xxxxxxxxx> wrote:
>>>> 
>>>>>> 
>>>>>> 2) It also means we create an option that will get deprecated once v2 is
>>>>>> phased out so we are adding a "temporary" option for users to "keep
>>>>>> creating v2 addresses" but then will be useless and we'll deprecate and get
>>>>>> a whole lot confusing if for instance v4 or v5 happens in the next years
>>>>>> for X reasons (unlikely but not impossible).
>>>>> 
>>>>> Not if we use the existing HiddenServiceVersion option for this.
>>>>> 
>>>>> Here are the use cases for this option:
>>>>> * a developer wants to test that their software works with V3 onion services,
>>>>> before the default is changed,
>>>>> * a user wants to run their old software with V2 onion services, after the
>>>>> default is changed.
>>>> 
>>>> Running v2 onion is fine, it's creating v2 onion that I don't want the user to
>>>> control when that tor supports v3.
>>> 
>>> But what if I have a tor client that only supports v2 onion services,
>>> (because it has not been updated yet, or is not maintained,)
>>> and I want to use it with a version of tor that only supports v3
>>> onion services? (because it has other security fixes I want)
> 
> Ok, I see your point. If some HS operator has a large client base and they are
> all v2 and that operator updates to a tor with v3, creates new HS well all the
> clients can't reach that new service so a "transition" period would be
> desirable.
> 
> To be honest, this is a tough one to answer.

Also, what if the software or library you are using to create onion services
only supports v2?

What if the program that creates onion services for you only supports v2?

What if the program uses v2 addresses as a persistent, self-authenticating
identifier? (Ricochet is a good example of all these issues.)

> ...
> 
>> Yes, the onion-service-version and the version of the descriptor that tor
>> publishes are now tightly coupled, comparing v2 and v3.  However, this may
>> not always be the case and, indeed, was not the case previously. I'm not
>> saying HiddenServiceVersion is not the correct torrc option, but please keep
>> these problems in mind. Also, realize that the current torrc syntax allows
>> multiple versions (so it would allow tor create both a v2 and v3 descriptor,
>> and if this is used for onion service creation, it could create both v2 and
>> v3 rend services).
> 
> That's another possible thing we could do but it has some possible UX
> consequences. Let's say we have a tor version that by default creates both
> version for a configured HS. You would end up with two addresses for the same
> service and then the operator broadcast those somehow to their users.
> 
> I have this feeling that it could be more of a mayhem of confusion for
> clients. The 16 char onion will always work but then clients trying the 52
> char onion (because they were told it's MORE secure) might fail not realizing
> that their client is v2 only…

So add a warning message *now* (to 0.3.0) that recognises v3 addresses and logs
a sensible message?

And discuss with Tor Browser etc. how to show it in the UI?

> and then we end up with all clients using the
> v2 address. What will happen at the next tor version which will phase out v2?
> We end up with the same problem again... old clients and so on.

Yes, there is a need for a transition period where both v2 and v3 work.

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------



_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev