[tor-dev] [RFC] Directory structure of prop224 onion services

[teor]

> On 1 Feb 2017, at 01:36, David Goulet <dgoulet at ev0ke.net> wrote:
> 
> On 31 Jan (09:02:35), teor wrote:
>> 
>>> On 27 Jan 2017, at 01:58, David Goulet <dgoulet at ev0ke.net> wrote:
> ...
> Your next question is a good one actually so jumping into it!
> 
>> 
>>> Current implementation doesn't allow two services in the same HiddenServiceDir
>>> and for prop224, the ongoing implementation doesn't allow it either. Sharing a
>>> directory brings all sorts of uneeded complexity. So if the directory is v3,
>>> everything in it will be v3.
>> 
>> How does an application tell the difference between a v2 and v3
>> directory?
> 
> Right now, apart from the "key tag" in the public key file that will be
> something like "v3", I don't see any :S ... And I think you are raising a good
> point. How can we make it easy for any application *only* looking on disk what
> version the hidden service is?
> 
> The onion address has the version encoded into it *but* that would require the
> application to do some base32 decode and truncation magic. Not user friendly
> enough? Maybe but apart from that, we would need to make it obvious either
> with a filename or litterally an extra "version file".

I think this would be a good idea:
* version 2 hidden services have no version file
* version 3 hidden services have a version file with "3" in it
and so on...

> However, there is kind of an issue rising from this. Imagine that v4 changes
> the onion address format because new crypto. We'll end up with a problem where
> the how to extract the version from the address is actually version
> specific... A solution to that is that "whatever size/encoding the address is,
> version will ALWAYS be the last 1 byte."
> 
> Thoughts?

I think it is a good idea to make the version the last byte of the
address.

But I also think that a version file is a good idea to make it easy for
applications to discover the on-disk version.

Otherwise, the algorithm would have to be something like:
* look for a hostname file
* read the first line
* find the address in that line
* if the address is N characters long, version 2
  * do we promise we will never have addresses this long in future versions?
* base32 decode that line
  * do we promise addresses will always be base32?
* read the last byte
  * do we promise addresses will always have the version in the last byte?

>> 
>> What's the supported method, that we will continue to support in
>> future, regardless of key or algorithm changes?
> 
> Not 100% sure what you mean by "supported method" but I'll take a guess. Those
> are the one that comes to mind:
> 
> - Single onion service
> - Client auth (only basic for now, we don't have stealth specified)
> 
> Also, every single Hidden Service torrc option will be supported for v3
> *EXCEPT* the Tor2Web one.
> 
> Hope that answers.
> ...

Actually, what I meant was:
"What can an application do to find the hidden service version, that we
always promise will work in any future version?"

That's what we're discussing above.

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
------------------------------------------------------------------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170201/fa7c76d2/attachment-0001.sig>