Re: [tor-dev] Discussion on the crypto migration plan of the identity keys of Hidden Services

[Matthew Finkel <matthew.finkel@xxxxxxxxx>]

On Fri, May 17, 2013 at 06:23:28AM -0700, George Kadianakis wrote:
> Greetings,
> 
> I'm supposed to write a Tor proposal for the migration of the
> long-term identity keys of Hidden Services. When I began writing the
> proposal, I realized that some of my choices might not be appreciated by
> Hidden Service operators, and that starting a discussion thread might be a
> good idea before writing the proposal.
> 
> The problem with the current long-term HS identity keys is that they
> are RSA-1024 keys which are considered weak, and they need to be
> upgraded to a cryptosystem with higher security properties.
> 
> One of the main issues with this operation, is whether Hidden Services
> will be accessible using their *old* identity keys even after the
> migration.
> 
> That is, when we change the identity keys of a Hidden Service, its
> onion also changes (since the onion is the truncated hash of its
> public key). This will be quite problematic for Hidden Services that
> have a well-established onion address.
> 

Do we have any idea how many of these well-established HS exist? I
expect the majority are simply "bookmarks" (or the respective service's
equivalent) so updating the specific entry would be the hardest part
about this transition, from the end user's point of view.

> There are basically two ways to do this:
> 
> a) After the transition, Hidden Services can be visited _only_ on
>    their _new_ onion addresses.
> 

Hrm...

>    This is quite brutal, but it's the most secure and unambiguous
>    option (might also be easier to implement and deploy).
> 

Agree.

>    This change can be enforced both on the client-side, by rejecting
>    any old RSA-1024 HS keys, and on the server-side, by only
>    publishing the new keys in HS descriptors.
> 

Agree.

>    To make the transition easier, we could prepare a tool that
>    generates a new identity keypair before the flag day, so that
>    Hidden Service operators can learn their future onion address
>    beforehand and announce it to their users.
> 

Ideally this is the best option, but realistically I think we all know
it isn't. So,...

> b) After the transition, Hidden Services can use both old and new
>    onion addresses.
> 

Yup.

>    This might result in a more harmonious transition, where Hidden
>    Services advertise their new onion address to users that visit
>    them in their old address.
> 
>    .oO(It would also be interesting to do a redirection on the Tor
>    protocol layer ("I got this descriptor by querying for the old
>    onion address, but it also contains a new onion address. I should
>    probably use the new one."), but I don't think it's possible to
>    redirect the user without knowledge of the application-layer
>    protocol (e.g. 302 for HTTP). Still, a Tor log message might be
>    helpful.)
> 

This would be a nice feature, but the current service descriptor
doesn't have any room for this additional information. We'll need to
develop a V3 service descriptor format to support longer "onion
addresses"/service id, in any case, so adding another field for
"Also-Known-As" may be a useful thing to have. It might be a good idea 
to also add a few reserved-for-future-use fields, along with it.

>    The cons of this approach is that supporting both addresses might
>    make the HS protocol more complicated and painful to implement, and
>    it might also result in some Hidden Services never moving to the
>    new onion addresses since clients can still visit them using the
>    old insecure ones.
> 
>    This approach has a stricter variant, where the old addresses can
>    only be used during a transitionary period (a few months?). After
>    that, clients _have_ to use the new addresses. Of course, this
>    means that we will have to do two flag days, coordinate Tor
>    releases, and other no fun stuff.
> 

I think this will be necessary. We'll probably need to have the new
scheme operation for an extended period of time before the so-call flag
day (that's an actual day in the US, you know...Flag Day :)). I think
anything less than 6 months will be too short. This will also be
dependent on how quickly this is implemented and how quickly the the
version of Tor in which this is implemented becomes stable.

I think the easiest solution (but not necessarily the best) will come
down to a transition/migration to a new descriptor format. There will be
a period of time where both descriptor formats are valid and either of
them will be returned by the HSDir depending on the query it receives
from the client. If the client requests the descriptor of a "new
style/scheme" service id, then return the V3 descriptor. If the client
requests an "old style/scheme" descriptor, then return both unless the
the client specifically states a descriptor version or the client's Tor
version does not support one of the descriptor versions.

After the flag day, it'll be hit-or-miss as to whether a V2 descriptor
is available depending on what the HSDir supports. Or, maybe at that
point in time, the DirAuths only give a relay the HSDir flag if it is
running >= x.x.x.x verion which only supports the new descriptor
version, thus finalizing the obsoletion of the old version and service id.

> I'm probably moving towards the latter option because the former will
> make many people unhappy.
> 

Yeah, unhappy people are both no fun and more likely to be confused by
the new system.

> Thoughts?
> 
> (This is not a thread to select the cryptosystem we are going to
> use. It will derail the discussion, and we might also need to select a
> specific type of cryptosystem in the end (e.g. a discrete-log-based
> system) so that schemes like
> https://trac.torproject.org/projects/tor/ticket/8106
> can be possible.).
> 

Just some thoughts off the top of my head (and wanting to revitalize
the conversation, mostly).

- Matt
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev