[tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

[teor]

> On 7 Feb 2017, at 21:33, Michael Rogers <michael at briarproject.org> wrote:
> 
> On 05/02/17 07:44, Taylor R Campbell wrote:
>>> Date: Sat, 04 Feb 2017 20:14:00 -0600
>>> From: Vi Grey <vigrey at riseup.net>
>>> Also, should we consider including a Version option eventually in the
>>> ADD_ONION control port command when using a KeyBlob?  It wouldn't matter
>>> much for this new version and probably wouldn't matter much for a while,
>>> but it might be good to keep this in mind for the future.
>> 
>> Versioning onion addresses and versioning network-internal service
>> descriptors need not be done the same way.
>> 
>> Addresses are likely to be long-term, and should really change only if
>> the meaning of the encoded public key has changed incompatibly but
>> otherwise imperceptibly -- e.g., if for some reason Tor switched from
>> Edwards coordinates to Montgomery coordinates on Curve25519.  (That
>> would be a silly thing to do -- it is just an example of a change that
>> could still interpret existing addresses, but differently.)
> 
> It seems to me that different people in this thread have different ideas
> about what the version number in the onion address represents, and it
> would be good to make that explicit in the spec. Does it represent:
> 
> 1. The version of the *onion address format* - meaning that, for
> example, a v4 address and a v5 address could point to the same
> descriptor, which would be compatible with both addresses?
> 
> 2. The version of the *descriptor format* - meaning that a v4 address
> must point to a v4 descriptor, but a v4 descriptor and a v5 descriptor
> could point to the same hidden service, which would be compatible with
> both descriptors?
> 
> 3. The version of the *entire protocol* - meaning that a v4 address must
> point to a v4 descriptor, which must point to a v4 hidden service?

At the moment, all 3 will change between versions 2 and 3.

In future, it depends.

It also depends how you define "the same hidden service", as many hidden
services can front for the same backend service.

Tim

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: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170208/99af1259/attachment.sig>