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

[David Goulet]

On 31 Jan (09:02:35), teor wrote:
> 
> > On 27 Jan 2017, at 01:58, David Goulet <dgoulet at ev0ke.net> wrote:
> > 
> >> - "./hostname"    [FILE]
> >> 
> >>   This is a file containing the onion address of the onion service.
> >> 
> >>   As you can see it's the same filename as in v2. Should we suffix it with v3
> >>   to make it clear that it's v3 onion? Would we ever have v2 and v3 onions
> >>   living in the same directory?
> > 
> > I don't believe we should suffix here because for almost 10 years, users/apps
> > have been exposed to "hostname" and it does make sense that it's the goto file
> > for that.
> 
> This works for applications that simply display the hostname without any
> further processing.
> 
> But code that expects a short hostname file may become confused when
> exposed to a longer hostname. It may fail silently, refuse to work,
> or have some other issue.
> 
> Have you tested any applications that use the hostname file with longer
> names?

To be honest, I would really hope applications just don't blindly open the
file and regex on a 16 char onion... They will be really sad with client auth.
But, we can't assume they are all perfect so yes that could be a problem. And
I hope that if it's the case, they error gracefully if regex fails. It's kind
of unreasonable to ask us to make sure we don't break any applications out
there doing such. The only assertion they should make on the "hostname" file
is that it contains the address of the address.

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

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?

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

Thanks!
David

> 
> 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
> ------------------------------------------------------------------------
> 
> 
> 
-- 
laomWpXMwfgJQSD00XsC6WR0haEh1gK8WeNTaAPQf20=
-------------- 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/20170131/524fec06/attachment.sig>