On Sat, 12 Oct 2013 19:03:44 +0100 Leo Vegoda <[email protected]> wrote:
> How is key management handled? Ok, first I want to summarize again, incorporating the changes made after Bjoern's commants. We are now looking at a two level key exchange, one with a 'public' public key, and a second with a 'private' public key. And I am trying to keep this just two buttons, 'Friend' and 'Unfriend' to make it as simple as possible. This is for the case where the MUA is 'default deny' aware. (If not available yet, this would be trivial to do with a small helper program or plugin, since SMTP is such a simple protocol). I am using 'sender' as the person who wants to initiate this, who could be unknown to the 'recipient'. Note that some state during the 'friend' process has to be kept by both sides, somehow. Not hard. Somewhere in the email program's setup prefs are two options: /X/ Use Private public keys for friends (use the two level keys). ON by default. /_/ Use Individual Super Private Keys for friends. (off by default...maybe). This forces a new, individual 'private' public key (keypair, actually) to be created for EACH friend. This provides some additional protection in case senders machine is compromised - only THAT private public key will be compromised. OK, I am the sender, and I want to send to someone who may or may not know me. 1. I hit the friend button. I may have an email message from the person, or maybe not. The MUA creates a blank, unencrypted email for me, getting the TO: either from the email I have up in view or prompting me for it. The program sees that I do not have a public key for this person and no transaction is already in progress, so it knows this is the initial state. I write the email, and had better be convincing about why I want to be friended if the other person does not know me. Send the email. Program changes the state of this transaction to a state where it is expecting a public key to be sent back. Note that no key is sent within this step, and the email must be unencrypted. 2. The recipient gets the email, and now has a choice to friend me or not. To friend me, he hits the friend button. Note that the onus here is on the recipient, this is exactly the opposite of normail email, where anyone can spam you and then you have to take positive action (like blocking) to prevent any more mail from that source. Here, if recipient wants no encrypted email from this source, they just do nothing. Now his MUA checks state, sees it is time to send his 'public' public key to the sender. It sends his public key, unencrypted. State is changed. 3. Sender gets public public key from recipient, and sends senders public key back, still unencrypted. 4. Recipient gets 'public' public key from sender. Now we have a way to encrypt mail successfullly on both ends. Recipient encrypts recipients 'private' public key with senders 'public' public key and sends it to sender, who will now be able to decode it. 5. Sender decrypts recipients 'private' public key. Sender now encrypts senders 'private' public key and sends it to recipient, who can now decode it. Sender now switches the 'active' public key from the 'public' public key to the 'private' public key, and notifies the senders MTA to whitelist the recipient for encrypted email. 6. Recipents gets senders encrypted 'private' public key, decodes it. Recipient now switches the 'active' public key from the 'public' public key to the 'private' public key, and notifies the recipients MTA to whitelist the sender for encrypted email. Friending completed. All done with one button press from each side, everything else is automatic. Only email is used for the whole transactions, no keyservers or other side channels needed. The public keys _actually used_ by both sides have never been sent in the clear. The private keys have never been sent anywhere either, of course. Not very fast, be we do not really need fast for something like this that just happens once. Spammer can send all the unencryted 'requests' they like, but they can do that now. Only the recipient can actually initiate the automated stuff, so there is no DOS type leverage from automated emails. Possible spammer actions: 1. Try to use the 'public' public key and forge senders email address. A pointless exercise since recipient will not be able to decode it, they are expecting encrypted mail to use the 'private' public key. 2. Compromise senders system obtaining the private private key. Always a danger, but spammers depend upon being able to send millions of emails easily. Not practical to have to compromise every one of their spam recipients machines, and how do they know who has friended who? Only a mass surveillance state actor could do this, and whatever you may feel about that, so far they have not resorted to spamming. ;-) Both of these attempts would incidentally provide a pretty much 100 percent sure way to filter the emails out as spam. Though, if my friends system was compromised, and the spammer sent me spam, I would consider that valuable information since it would tell me my friends system and my private public key were compromised. > Managing scheduled key rollovers > might be easy enough but what about unscheduled key rollovers when > a system is compromised and the old keypair needs to be revoked and > a new keypair needs to be created and publishedr? OK, this is a special case. If I hold down the shift button in my MUA, the 'friend' button changes to 'refriend'. This means 'make a new 'private' public key (pair), and do the 'private' public key exchange again. Of course will want to make sure my friend has cleaned up his system first. On his end, his private keys are compromised too, so he has to hold doen the shift and control keys to see the friend button change to 'Redo all' or 'Was Hacked' or something similar. May want to keep the old keys to be able to read old emails, but they will no longer be current. Both the 'public' public and private keys will be remade, and the 'private' public and private keys need to be remade in his case. If neither of us was actually compromised, and we just want new keys (new 'private' public keys) for some reason, we both just hit the 'refriend' button. All else handled by the MUAs. Something like that. > Making good key management lightweight strŅkes me as a hard problem. > Is that wrong? You tell me. Will the above work? Seems pretty simple to me. I am not a security expert though, just a poor user who wants this to all be MUCH easier (for end users, system admin users, and programmers). Where are the flaws? I think what makes present key management hard in email is the current assumption that 'anyone must be able to email anyone at any time' - default accept, in other words. To do this you need things like public keyservers, or some other way that keys can be easily known. Default deny for encrypted email removes that problem, since both sides must already be known to each other. Remember my goals: Get everyone to use at least some email encryption by making it really simple to use, and having a reason (less spam) more instantly apparent than just privacy. Perfection not required. I'm sure this could be probably be MITMed but to do that someone has to go to much extra effort. And the thing is, pretty much everything we are using now has had serious, sometimes 'banging head on desk' 'how could that possibly have been missed' problems at one point or another. Get everyone using this, we can then later come out with version2, which is MUCH easier to do that just getting everyone on board to start with. There would also still be the option of exchanging keys manually. You could still perhaps build in some 'web of trust' type checks with keyservers (for the 'public' public keys). First you have to get the users hooked. THEN up the ante. ;-) -Mike _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
