-- Leo's gemini proxy
-- Connecting to bbs.geminispace.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
Thanks @totroptof :) some interesting thoughts.
Bubble has a mechanism to set a temporary password to allow you to link a new certificate, but that doesn't help with recovery if you lose a certificate. I guess today you'd email Skyjake.
Email addresses and domains will probably be used as fallback proof of identity when certificates get lost.
I suppose the ideal setup today is, you should export and back up your certificates. Backup is hard to get right, it's a lot to ask of users.
Account recovery is a really hard problem. I suppose we are not going to have a centralized service where you can recover access via a code sent to your phone :)
2023-06-19 · 11 months ago
@Morgan: Reading your reply, I’ve realised I wasn’t really clear on what point I was trying to make. This is my second attempt after thinking about it for a bit 🙂
A motif I’ve noticed browsing some of the more technical writings in Geminispace is that many Geminauts don’t really seem to take security that seriously. That’s not necessarily a criticism; I think there are reasonable justifications for this position, particularly in the context of Geminispace. However, if the goal is to build a system that addresses some of the attacks made possible (in part) by this lack of security culture, I believe a system that isn’t designed for inevitable key compromise will fail to meet its goals.
To clarify, I don’t think “design[ing] for inevitable key compromise” means recovery codes sent by SMS. Looking at operators elsewhere on the internet, one can observe things like Let’s Encrypt restricting certificate validity to a maximum of three months and wide deployment of ratcheting key agreement systems in chat applications. To me (and please note, I’m no cryptographer), designing for key compromise looks like a focus on ephemeral (or at least relatively temporally limited) keys, regular rekeying and per-device keys. I’d argue that a system which requires users to export and back up private keys is the exact opposite, since
the nature of fixed (or very infrequently rekeyed) private keys makes any successful attack catastrophic, and
every interaction with keys, by person or program, is an opportunity for attack, and
disseminating keys amongst systems for back-up or multi-device authentication enormously multiplies the attack surface.
In the writings of solderpunk and others on the topic of Gemini I perceive a philosophy that’s essentially humanist with a particular de-emphasis on technocentric approaches. The “solutions” to the identity problem I posed in my last comment, as impractical as they are, were an attempt to try and examine the problem space in a way that seemed more consistent with this philosophy.¹
I hope that’s a bit clearer (it is for me at least :P)
Footnotes
─────────
[1] I don’t mean to imply an endorsement of those values; in fact, it’s a topic I intend to glog about at some point. 😉
Thanks @totroptof
Some more thoughts from me, although I'm no expert either :)
I think short key expiry is a distraction--it seems like what you want is secure key changes, backup proof of identity and intrusion detection. All of these are hard :)
But not entirely hopeless.
For example, you could have a second key pair that you print and keep only on paper. It's your emergency key in case you need to change the live one or regain control of it.
So that maybe covers secure key changes and backup proof of identity.
It would be nice to have intrusion detection, but I don't see how. For example, a server could notice that you are acessing your account from the other side of the world to where you usually are--by IP address--and ask for confirmation before trusting your cert from your new location. This would catch a lot of compromised keys. But it requires a level of sophisticated tracking and centralization unlikely to come to Gemini. Not saying that's a bad thing--just means it's a different problem to web account security.
I suppose "here is the latest activity associated with your cert" is a form of intrusion detection we could have on Gemini in a distributed way. Then if you see activity you don't recognize you can trigger a key change using your offline key. Somehow.
Fun stuff.
I̶n̶ ̶c̶a̶s̶e̶ ̶I̶ ̶f̶a̶t̶-̶f̶i̶n̶g̶e̶r̶ ̶s̶o̶m̶e̶t̶h̶i̶n̶g̶ ̶a̶n̶d̶ ̶a̶c̶c̶i̶d̶e̶n̶t̶a̶l̶l̶y̶ ̶p̶o̶s̶t̶ ̶t̶h̶i̶s̶ ̶a̶s̶ ̶a̶ ̶c̶o̶m̶m̶e̶n̶t̶ ̶i̶n̶s̶t̶e̶a̶d̶ ̶o̶f̶ ̶a̶ ̶d̶r̶a̶f̶t̶:̶ ̶t̶h̶i̶s̶ ̶i̶s̶ ̶j̶u̶s̶t̶ ̶m̶e̶ ̶j̶o̶t̶t̶i̶n̶g̶ ̶d̶o̶w̶n̶ ̶s̶o̶m̶e̶ ̶p̶o̶i̶n̶t̶s̶ ̶t̶o̶ ̶t̶h̶i̶n̶k̶ ̶a̶b̶o̶u̶t̶ ̶:̶)̶
Incredibly, exactly that happened. Sorry 😵💫
No worries :)
Gemini Identity — @Morgan has a prototype implementation of an identity service for Gemini. This is certainly interesting! Some quick thoughts: If this is something that people want to use, it should not rely on a single central server. Anyone should be able to self-host their identity service and servers should not assume a default one. How does this mesh with people not wanting to be tracked across...
-- Response ended
-- Page fetched on Sun Jun 2 13:26:43 2024