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

[teor <teor2345@xxxxxxxxx>]

> On 24 Nov. 2016, at 10:43, s7r <s7r@xxxxxxxxxx> wrote:
> 
> 
> teor wrote:
>>>> 
>>>> How does ADD_ONION fit in?
>>> 
>>> It's forward compatible by design, since you have to specify a key type
>>> when you handle key management, and Tor gets to do whatever it wants if
>>> you ask it to generate a key with the `BEST` algorithm.
>>> 
>>> Assuming people who use it aren't explicitly asking for RSA1024, their
>>> apps will magically switch to using Ed25519 automagically one day, when
>>> their tor is updated.
>>> 
>>> (People who expect `NEW:BEST` ADD_ONION-ed services to always give
>>> RSA1024 based HSes, should fix their code since the spec makes no
>>> guarantee that `BEST` will be RSA1024.)
>> 
>> +1
>> 
>> (I've changed my opinion, adding a new command is pointless.
>> People who want the old ADD_ONION behaviour where BEST produces a v2 HS
>> can use an older version of Tor, until the software that makes
>> incorrect assumptions is updated.)
>> 
>> T
>> 
> 
> I agree that this would be "the technical way" to do it, but real world
> usability kind of prevents us to do it this way. The spec for ADD_ONION
> indeed does not say that v2 hidden services will be supported forever
> and it clearly SHOULD NOT, but it also doesn't make much sense to
> abolish it at the first Tor release supporting v3 services (because if
> we make ADD_ONION == v3 (best) this is what we are doing).

No-one is proposing we abolish ADD_ONION with v2 services straight away.

What we will do is make BEST mean v3, rather than v2.
RSA1024 will continue to mean v2, as it always has.

ADD_ONION has always had an explicit BEST option, if clients don't want
the BEST type of key, they should ask for a specific type they are
prepared to handle.

Please read the appropriate control spec section:
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1446

> I don't think it's productive to ask users to already support a new
> feature upon our first release providing the said feature.

This isn't what is proposed.

(We are going to stop automatically creating v2 services via
HiddenServiceDir in the first v3 release, but there will always be the
ability to manually create a key. And that's a separate conversation.)

> To add some value on this point, I will bring into discussion a software
> that is widely used, produces significant rendezvous traffic and is
> important for some people:
> 
> Bitcoin Core - latest versions detect if you use Tor and automatically
> use ADD_ONION to create v2 services, and, important: it doesn't support
> yet the v3 address types because of their length.

Does it use ADD_ONION NEW:RSA1024 or ADD_ONION RSA1024:<String>?

Then it will be fine.

Does it use ADD_ONION NEW:BEST?

Then that's a client bug, and it should be fixed in the client.

> ...

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