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