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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
