[tor-dev] Remaining 4 bits in prop224 addresses

[David Goulet]

On 06 Dec (17:47:01), Jesse V wrote:
> On 12/06/2016 11:27 AM, David Goulet wrote:
> > We had little discussion but some of us agree for sure on having bits for the
> > version number. That will tell a tor client to fetch the right descriptor
> > instead of trying all version that have the same type of public key (.onion
> > address). We currently have I believe 4 bit left which is only 16 values so we
> > could extend to one more byte here so have more room.
> 
> I'm curious if we ever ran into this issue with the current HS protocol.
> What type of changes would warrant a new address that that could not be
> solved with a patch to the tor binary? We also need to consider the
> difficulty of distributing a one-character-different address against the
> difficulty of transitioning the network to the new descriptors. People
> get very entrenched to their onion address, bookmark them, and some even
> issue SSL certs for them.

Descriptor have a version which is basically the HS protocol, IP have a
subprotocol version, RP have a subprotocol version, HSDir have a subprotocol
version, there are really lots of values :).

IMO, adding a version to the address would be the version of the HS protocol
because the address (for prop224 it is your public key) is litterally
cryptographically tied to the descriptor. Imagine in 6 months after v3 is out
we go to v4 because we need to add a field to the descriptor for X reasons, v4
addresses will be generated with a version "4" in it so client can fetch do
the fetch for a v4 descriptor (yes the version is in the URL of the request to
the HSDir) instead of being confused and trying v3 and then v4. This is
considering of course that the length between v3 and v4 is the same. Different
length makes it "easier" but yet we shouldn't rely on that for any versionning
scheme.

That being said, you are right that people get very entrenched to their .onion
*especially* with EV certificate nowadays or bookmark but encoding a checksum
or/and version will indeed make a part of it different for some feature
gain... not easy problem user wise... :S

> 
> Let's say we added another character, so that we have 9 bits free. Would
> would be the consequence of using all 9 bits for a checksum? We could
> solve the version/descriptor issue using a naming system and simply
> point the name to a newer onion address. It's something to consider.

Yes, _ideally_, naming transport should be our way forward else we'll loose
this battle of security vs usability. Onion address _have_ to get bigger
unfortunately. Proposal 274 (which is stuck on tor-dev@ I realize) is imo a
really good way forward (A Name System API for Tor Onion Services).

> 
> > Second thing that is possible, like you stated above, is a checksum.
> > Unfortunately, I haven't thought much about this nor know the "state of the
> > art of small-checksum" but definitely something to dig through! Jessie, if you
> > feel like it, I welcome any analysis you can do on checksum here and some
> > proposal about it. (Only if you want to :).
> 
> I'm not fluent in the arts of small checksums, but it seems to me that
> we do have some benefit of using the first N bits of SHA2(version +
> edDSA_address) as the checksum. I may not have time to write a full
> proposal, but even with a small number of bits we do have a decent
> chance of catching typos, which is the whole point. Obviously, this
> chance will get better as you add more bytes, but prop224 addresses are
> already fairly long and we should weigh the usability impact against the
> probability of typos.

teor's reply seems reasonable so far about that :). I just wonder how much we
truncate.

David

> 
> -- 
> Jesse
> 
> _______________________________________________
> 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/20161206/697736ef/attachment.sig>