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

[Matthew Finkel]

On Fri, May 17, 2013 at 03:44:27PM +0200, Jeroen Massar wrote:
> On 2013-05-17 15:23 , George Kadianakis wrote:
> [..]
> > 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.
> 
> (just a brain ramble might be something useful, might be useless ;)
> 
> Each hidden service could run, on a given port/protocol, a service that
> answers with the hashes it is responsible for (a 'service packet'), eg
> by signing the packet with each of those sigs. The client can thereby
> know that that service is available as different hashes.
> 
> The 'service packet' could indicate a 'hash preference' thus enabling
> the client to pick the 'preferred' hash, and effectively allowing
> multi-homing of the service if the preferences are the same and/or
> allowing moving to a new crypto key, quite transparently, as the
> old-hash is still available and can be checked.
> 

So you're imaging the ability to query the HS directly and request
additional information? I think this is a good idea, in general, but HS
 are tricky. As they are right now, they can be forced to talk, which is
 a significant problem. Allowing additional querying will only add to
 this problem. Adding another trusted-third party for holding these
 mappings may be an option, but that also adds the the complexity of the
 system for an as-of-yet-unknown benefit (as far as I can tell).

> Note that it requires being able to sign those packets with the new
> hash, thus one has the private key for being able to do that, no
> cheating would be possible.
> 
> The 'service packet' could contain a "well known name" or "description"
> so that these packets can be stored/indexed and the user can use this
> identifier for accessing the service.

This would be very useful, but still as above.

> 
> Of course, the question also becomes 'is the old one still valid or has
> it been compromised', that is a hard one to answer... I guess having an
> expiry of a key would be a good thing.
> 

Tom's system may be able to provide some sort of guarantee.

> 
> An alternate approach, given a DNS tree where due to DNSSEC it is
> trusted (yes, that comes with a lot of it's own caveats ;) ) one could
> state hidden.example.com has a CERT [1] record which has hash X and hash
> Y. That would be the forward mapping at least. A DANE[2] alike system
> also come to mind.
> 
> [1] https://tools.ietf.org/html/rfc4398
> [2] https://tools.ietf.org/wg/dane/
> 

This is definitely a good starting point, but I hope we can develop a
solution that is less complex and more suited for our goals.

> Greets,
>  Jeroen

Thanks!
- Matt