Subject: Re: [perpass] A proposal for developing PRISM-Proof email (default deny)

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 10 Oct 2013 00:00:31 +0200

* Mike Demmers wrote:
>TThe basic concept of default deny for encrypted emails only seems very 'right' to
>me, because if you are going to the trouble to do this, and handle things like
>key exchanges, that communication must be pretty special to begin with. Why would
>you want 'just anyone' to be able to send you encrypted emails?

I got the PGP key in my signature particularily so that strangers can
contact me in a somewhat confidential manner (that was in 1999 when I
was still in secondary education, and pretty much everybody I knew at
the time would have better ways for confidential communication, but
strangers living thousands of kilometers away lacked those options).
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mike Demmers <[email-masked]>
Date: Thu, 10 Oct 2013 05:00:40 -0700

On Thu, 10 Oct 2013 00:00:31 +0200

> strangers living thousands of kilometers away lacked those options).

If using default deny for encrypted email, they would simply have to first send you a non-encrypted email that said something like "I would like to exchange email with you confidentially and have added your address to my 'allow' list, would you add me to yours?"

Would this be a problem? Remember, this is email, and PGP - the fact that they are contacting you is not hidden in either case, just the actual content.

Of course, if you ONLY want encrypted email communications in that circumstance, you might want to just turn off default deny. I am suggesting this as a standard default, not as something required - the user must always have the choice.

In the case of someone with no previous contact, if they tried to send you encrypted email, they would get an immediate bounce with an error message something like:

550 "Email rejected because not on users whitelist. Please ask for whitelisting in an unencrypted email."

Ideally, user email programs would have some really simple ways to handle this.

-Mike

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 10 Oct 2013 14:44:45 +0200

* Mike Demmers wrote:
>If using default deny for encrypted email, they would simply have to 
>first send you a non-encrypted email that said something like "I would 
>like to exchange email with you confidentially and have added your 
>address to my 'allow' list, would you add me to yours?"
>
>Would this be a problem? Remember, this is email, and PGP - the fact 
>that they are contacting you is not hidden in either case, just the 
>actual content.

Back in the day it did not seem unusual for people to know about things
like anonymous remailers or how trivial it is to manually deliver mails
by typing SMTP commands into a console, including spoofing various bits
of header data, so that did not seem that big an issue to me.

There are a couple of problems with your approach above. One is knowing
whether and when you have been added to someone's `allow` list. Another
is that people can include the encrypted message in their request to be
put on the `allow` list if they can somehow obtain the recipient's key,
rendering the request redundant. Spammers can ask to be put on the list
just like anybody else.

>In the case of someone with no previous contact, if they tried to send 
>you encrypted email, they would get an immediate bounce with an error 
>message something like:

That would be a bad default policy: can be abused to verify addresses,
disclose encrypted email policy, recover parts of the white list if the
mail system allows address spoofing, doesn't work when the receiving
system is down for maintenance for an hour or two, mails might get lost
when the sender switches addresses or uses a wrong one by accident, ...
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mike Demmers <[email-masked]>
Date: Thu, 10 Oct 2013 09:25:04 -0700

On Thu, 10 Oct 2013 14:44:45 +0200

> of header data, so that did not seem that big an issue to me.

Oh, I don't think this is _quite_ to the level of telnetting to the MTA!

How about this:

There are two new standard buttons on the MUA: FRIEND UNFRIEND

Everything possible is set up by the MUA when it is first run - keys, made, if they do not exist, questions asked and answered about keyservers, pass phrases, various preferences etc. Same as it SHOULD be now.

"Coolmail has a new feature! You can 'Friend' people, and if they also friend you, you will be communicating privately from then on. Better yet, you will see no spam in this mode (unless you friend a spammer).

It's easy to use! When someone you wish to communicate with privately emails you, just hit the friend button. This will handle everything automatically. They will be sent a plain text message with your special key. And if they also friend you, their special key will be sent to you, if you do not already have it. (all automatic). 

You can also set up this feature to automatically check the keyserver of your choice in preferences/friending" blah blah blah..."

Something like that. Does not seem hard to me. Probably a bit less hard than learning how to add an attachment to an email, most everyone learns to do that.

You just have to hit one button, all else is handled automatically. 

> whether and when you have been added to someone's `allow` list. 

Works just like now: If you are on the whitelist, your mail just goes through. If not, you get a bounce.

As it works now: My mail goes through, unless someone has me blocked, in which case I get a bounce.

People are quite familiar with bounces.

> Another
> rendering the request redundant. 

But it won't be decoded, because it is not marked as encrypted email. If you are trying to spam me this way, I will not see it, so what is the point? Optionally I could just drop all such messages, as part of the normal spam filtering. A friend request with an encrypted section is invalid.

This is just ordinary non encrypted email far as the MTA system knows, and normal antispam measures will be applied.

The best way to get me to add someone to my allow list would be a plain email asking for that (perhaps with a reason so I can judge whether they are a spammer or not) but then don't worry about keys, just hit the friend button and let the system handle the key exchanges.

>Spammers can ask to be put on the list
> just like anybody else.

They can, but why would I add them? This is intended to be private email - friends, family, work, special people. The plain text mail system will still work just as now, for other purposes. 

It is also very likely that message from a spammer will be dropped by a blocklist long before I could see it. Most spam is either sent from (pretty quickly) known spam netblocks, or from hacked user machines, which are generally in ISP spaces labeled as such and mostly blocked (if you have any reasonable anti-spam system in place).

Another factor is that spammers just won't, for the most part, be willing to go through such a two step process. For one thing, most will be -technically- unable to do so, because they are using hacked systems and this setup requires a reply from the actual sender to work. That simply cannot happen for most spam, because it is using forged addresses in the from lines, most often to completely different systems.

-Friending is not complete until both sides have done the exchange.-

This is a bit like confirmed email lists. Spammers could get on my lists if they really tried, but what I actually see is that they do not go past the first step - they just try to send some spam, if that does not work, they just move on. Too much work for them.

OK, so...just checking the steps...

I get plain email requesting friend status.
I hit friend button, friend request is sent to original user, I am in half-completed friend state.
Remote user gets request, half friend status, hits friend button, sends friend request, marks as completed.
I get friend request, hit friend button, mark as completed.

I think that should work. An active friend button hit is required from both sides to complete. There had to be valid return addresses on both sides for this to work.

> That would be a bad default policy: can be abused to verify addresses,

No different than how email works right now. How is a bounce from this any different from a bounce for any other reason?

If you are a spammer you are sending out millions of emails. To verify an address is in my 'inner circle', you would have to try, what, 200 million or so guesses, of which about 1,999,990 would be negative.

Not likely to happen.

> disclose encrypted email policy, 

The policy is default deny. Pefectly public. Why not? Right now the default policy for -all- mail is default accept, and everyone knows this. 

That is all they can learn from this. The exact same bounce for every single email they try. Millions to get one good one. Defeats the cost basis of spamming.

> recover parts of the white list if the
> mail system allows address spoofing,

Again, millions to test. No spammer will do this. Most MTAs have limits on the number of addresses that can be tried, this is because spammers try to do that now with the existing mail system - this is no different and the same defenses apply.

Now, if they happen to KNOW the address of one of my 'friends', they could send me spam IF my key was in a public keyserver or they got it from an email sent from me, AND they forged the sending address.

A defense against that situation would be to have two sets of keys, one for initial contact that might be given out in an email, and once a secure setup was established, change to a second very private 'public' key, with the key exchange going through the already encrypted emails. This is kind of like how ssh works, I create 'public' keys for servers, but do NOT want those in a public keyserver or in emails. They are sort of private, public keys. 

> doesn't work when the receiving
> system is down for maintenance for an hour or two, 

No, perhaps you do not understand that this is blocking done by the MTA, not the MUA. If the MTA goes down, exactly the same thing happens that happens now: The mail is requeued by the sending MTA and sent later when the receiving MTA is back up. No difference from now.

> mails might get lost

Same as the existng system. User will get a bounce. They just need to 'friend' the new address. Or correct their error. Just like when you make a typo in an email address. Nothing will be lost. -This is not filtering.- It is mail bounces, done at the MTA, specifically because that insures against such things. The feedback is very fast to the user.

The changes to the mail system are extremely minor. The mailserver has a new way to handle the metadata that an email is encrypted - this is the only new feature change in the MTA. It is set to default deny for encrypted emails, using the existing system (same as used for anti-spam now) and to whitelist certain encrypted emails from that - again using the existing system. Everything else is unchanged, there is no more risk of losing emails or any other mail problem than there is now. For many different reasons, an email may bounce now - we have just added one new reason; a bounce is still a bounce and is handled exactly the same way.

The purpose here is to give the average user a reason to use encryption (anti-spam, some privacy where you especially want it). And to make it so easy to use that many people will.

It helps by at least providing some privacy for the user, and helps us all by the fact that if many people are using encryption, it changes the situation where if you are using encryption, that alone is cause for suspicion.

It does nothing to help the metadata problems of email, and no doubt NSA etc could MITM it pretty easily. But it's work to do that. And if it is encrypted, they cannot do trivial searches on plain text to accuse me of being a terrorist because I happened to need a new seal for my pressure cooker. They at least have to get my keys somehow and decode it, or MITM me. If they want me that bad, I figure I am toast anyway.

All the 'perfect' encryption in the world is useless if no one uses it, the way it is now. 

Get everyone on board, and I am sure things can be improved in time.

-Mike

---

From: Leo Vegoda <[email-masked]>
Date: Sat, 12 Oct 2013 19:03:44 +0100

On Thu, Oct 10, 2013 at 09:25:04AM -0700, Mike Demmers wrote:

[...]

> You just have to hit one button, all else is handled automatically. 

How is key management handled? 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?

Making good key management lightweight strіkes me as a hard problem.
Is that wrong?

Regards,

Leo

---

From: Mike Demmers <[email-masked]>
Date: Sat, 12 Oct 2013 23:45:00 -0700

On Sat, 12 Oct 2013 19:03:44 +0100
Leo Vegoda <[email-masked]> 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

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.

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

---

From: Leo Vegoda <[email-masked]>
Date: Sun, 13 Oct 2013 08:25:08 -0700

[...]

> > Making good key management lightweight strikes me as a hard problem.
> > Is that wrong?
> 

I am not a security expert either but presumably people will need to
export keys for backup and deployment on other systems. For
instance, many people have something like a laptop computer, a
smartphone and a tablet. Presumably, users would want to use the
same keys on all those devices so that they can read all their
e-mail no matter which device they use.

I also expect people would want to be able to revoke a key if a
device is stolen and then generate a new key to replace it, back
that up and distribute it to all the devices in use.

I think the UI elements for generating and publishing a key are
important but if the underlying key management doesn't meet people's
needs then your goal of getting people to use encryption won't be
achieved because the things they can do today won't be possible.

So my questions are:

- how do people use the same keys on all their devices?
- how do people securely backup their keys?
- how do people revoke keys when a device is stolen or otherwise
  compromised?

Regards,

Leo

---

From: Mike Demmers <[email-masked]>
Date: Mon, 14 Oct 2013 16:09:06 -0700

On Sun, 13 Oct 2013 08:25:08 -0700

> that up and distribute it to all the devices in use.

...

> So my questions are:

Excellent questions.

> - how do people use the same keys on all their devices?

OK. Keys are just small files. So this boils down to 'how do I securely transfer small files between my devices?'.

This involves private keys, so we really need to be a little careful with this one.

Here is how I think this might work:

Besides the normal keys that are generated when your MUA is first started, a 'device key' (device keypair, public and private key for the device) is generated. These are unique to each device, and you are prompted for 'device name' at some point ('Joe's tablet', 'Joe's Phone' etc.). So now we have a way to encode something that only one device can read.

But we need to exchange public keys. Since these are public keys, just about any way will work that will transfer a file. Best would be something completely local of course, but this could also be something like an attachment to an email. 

So: select menu item 'Friend a Device'

See:

"Friending a device means interchanging device public keys. This is required in order to be able to securely share your friending environment between all your devices that use email (home computer, tablet, phone, etc.). Each device must have the device public keys for all your other devices. This step only must be done once.

There are two ways you can make this key exchange:

1. You can export your device public key for the device you are currently using to a file, which will be called YOURDEVICENAME.devicepublickey. This is then copied to all your other devices using a disk, usbstick, local lan, or other means of locally copying files from one device to another. Then, on the other device, you select 'Import Other Device Public Key From file'. You must export the device public key from each device you use, and import it to the other devices.

This is the most secure means of making this key exchange since the device public key never leaves your local environment.

2. You can use email to send the device public key as well. This is slightly less secure, since your device public key will go over the network, where it could be seen by someone else. Your private key will still be completely safe though. This may be required for certain kinds of devices where other means are not possible. If you select this option, a new email message will be created, to yourself, that contains the device public key in the body of the email. You should send this, then on each device you wish to 'friend' as a device, call up the email and select from the menu 'Import Device Public Key From Current Email'.
You must do the to and from each device.

Select 'Method 1' 'Method 2' 'Abort'"

Now we have a way to encode transfers between devices.

To actually sync:

Select from menu: "Sync my complete email friending environment from this device to another"

See:

"Select device to sync to from list"

Select one.

"Select method:

1. Export to file, which will be called USERNAME.friendkeysenv. This will create a standard format file, encrypted with the other devices device public key, that can be copied over and imported and decoded.

2. Use email. This will create a standard format file, encrypted with the other devices public key, in the body of an email to send to yourself. Select 'Import Friend Environment From Current Email' from menu on the other device.

This will update all private public keys and private private keys on the remote device to be the same as on the source device ('master'). Any existing files will be overwritten."

That will sync a device to a master device, but we need another option, because life is messy. Ideally, we would have all our friending be on one device, and then replcate that environment to other devices. But people do not always follow such rules, and sometimes this is inconvenient or impossible.

So we also need a similar function that can copy just ONE new friend over to other devices. So if I friend someone on my phone in a meeting, I can later just import that one into my master.

This would work just like the above function, but would create a file with just one name in it, in some standard format, so the importing device will know to just append it.

Well, that's a bit awkward, isn't it? What I really want as a user is something like

Hit sync button

See 'Select device from list'

Everything else handled automatically.

Can that be done? 

The very first step, that only has to be done once - the initial device public key exchange, pretty much has to be done the way shown. We can't have a device just automatically grabbing anothers public key through some protocol, it would be less secure. The user really needs to be in control of that from the device sending the key, to be sure only his own devices are in his inner circle.

But after that...can't be done by the file method since we do not know ahead of time how files might be transferred between two random devices.

Perhaps through email, by keeping track of state similarly to how the friending stuff works. IF this became standardized, we would at least know that the email program on the other end (and we don't really have control of what email program is running on many devices, like phones) would be able to handle that somehow.

-This is important- 

A sort of 'Default Deny' standard way of creating these files and formats could be created, but what I really feel is that having a way of exchanging a crypto environment _that is tied to some particular 'Default Deny' standard or program is the wrong way to go. What I WANT to use for this is standard formats for keys, key exchanges, whole key environment exchanges, using standard methods. That could be used by ANY program.

The difficulties here point up a real, serious flaw in the current crypto ecosystem, I believe, which is this: there are not enough GENERIC standards for crypto. Mostly because all this is still really new, everything seems to have developed in isolation, each protocol or program more or less in its own world, tied to a particular program. Often even when doing identical things, names are different, locations are unpredictable. There are subtle differences in the way things are done that should be the same, and standardized.

For example, consider where my email public/private keys are kept for gnupg. They are kept in /~user/.gnupg/. They are actually in a little database, formatted in a certain way, probably unique to gnupg.
I suppose if I used pgp, they would be in ~user/.pgp/. Probably with  different format. My ssh keys are in /~user/.ssh, not in a database, stored in a different way. Here, even within a single application, all the private and public keys even have different names, and are stored in a different way. And not in a database.

id_dsa.pub
id_rsa.pub
identity.pub

Here we have some metadata in the actual name, but it is pointless, because:

# more id_dsa.pub 
ssh-dss AAAAB3NzaC...

that metadata is already in the file itself.

Ssh has a list of authorized keys in 'authorized_keys'. Whatever gpupgs equivalent is, is stored in a completely different form. Look up 'using gpg keys for my ssh keys' in Google to see people struggling to do something that SHOULD be simple. (Even if not, in my opinion, wise.)

Gnupg has other uses than just email, why tie all the email keys to this one program?

Why not have a generic place for those email keys, something like /~user/.crypto/email/publickeys/ with some kind of standard naming scheme? That way, if a user used two different email programs, things would just work the same. If you WANTED, for some reason, one to be different, just use '/~user/.crypto/email/publickeys/eudora/' as an override of the default. But that would be exceptional.

Having standards that put things in standard places with standard names and formats makes intoperability and writing helper programs possible. 

Crypto is complicated and affects security. You know what else is complicated and affects security? Networking. Consider the difference in how the two work:

Networking:

Some expert discovers a security problem with some protocol, say 'talk'. I want to know if I have this at all, and if is is running. What is 'talk' anyway? Look at the standard list of services in /etc:

# grep talk /etc/services 
talk            517/tcp                         # like tenex link
talk            517/udp

Not REAL helpful, but something.
# cryptstat
-bash: cryptstat: command not found

# man talk

NAME
       talk - talk to another user

OK, fine, some sort of chat thing, port 517 service. Is it available? Is anyone running this?

# netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      

tcp        0      0 *:submission            *:*                     LISTEN     
tcp        0      0 *:http                  *:*                     LISTEN     
... 

nope, so will not worry about this for now.

Crypto:

Some expert discovers a security problem with some crypto method, say '3des'. I want to know if I have this at all, and if anyone is using it. What is '3des' anyway? Look at the standard list of crypto methods in  in /etc:

Oops, doesn't exist.

OK, well, try:
# cryptstat
-bash: cryptstat: command not found

# man 3des
No manual entry for 3des

# man des

des(3)                                OpenSSL                                des(3)

NAME
       DES_random_key, DES_set_key, DES_key_sched, DES_set_key_checked,
       DES_set_key_unchecked, DES_set_odd_parity, DES_is_weak_key, DES_ecb_encrypt,
       DES_ecb2_encrypt, DES_ecb3_encrypt, DES_ncbc_encrypt, DES_cfb_encrypt,
       DES_ofb_encrypt, DES_pcbc_encrypt, DES_cfb64_encrypt, DES_ofb64_encrypt,
       DES_xcbc_encrypt, DES_ede2_cbc_encrypt, DES_ede2_cfb64_encrypt,
       DES_ede2_ofb64_encrypt, DES_ede3_cbc_encrypt, DES_ede3_cbcm_encrypt,
       DES_ede3_cfb64_encrypt, DES_ede3_ofb64_encrypt, DES_cbc_cksum,
       DES_quad_cksum, DES_string_to_key, DES_string_to_2keys, DES_fcrypt,
       DES_crypt, DES_enc_read, DES_enc_write - DES encryption
DESCRIPTION
       This library contains a fast implementation of the DES encryption algorithm.

Well, thank you openSSL, at least. I infer it must exist on my system somewhere since I have a man page for it.
# cryptstat
-bash: cryptstat: command not found

Is anyone using it? Try a little wishful thinking...

# cryptstat
-bash: cryptstat: command not found

Oops, no such program. No way to easily tell if someone might be running a serious security hazard on my system.

Not only does 'cryptstat' not exist, but it would be nearly impossible to write one. It would have to know every single crypto program that MIGHT exist on the system, what their formats are, how to discover what is currently seleted for use.

IETF is all about standards and interoperability. It's time for some in this area.

> - how do people securely backup their keys?

They get backed up when they back up their system.

They can also use the functions mentioned above to make a 'standard' crypto environment file to share between friendly devices, which has all their own and friends public keys, and their own private keys. Put it on a disk somewhere safe.

In a multi-device environment, if a single device loses a disk or somethng, they can just use the 'export to friendly device' from any of the remaining good devices to restore everything.

> - how do people revoke keys when a device is stolen or otherwise

I covered this previously - if your device is stolen or hacked, it is basically 'game over'. You need to use the functions that drop all your current private and public keys (to 'inactive' status), and create new ones, and refriend your email contacts that use encryption. Public key cryptography depends upon keeping your private key safe. I know of no way to change that.

As to 'revocation' - none needed (other than telling your friends to refriend you - the 'I was Hacked' menu item could possibly do that part automatically), because we are not using any public keyservers or Certificate Authorities external to our own envronment. There is nothing in public to 'revoke'.

I need to be very clear about what I am doing here by NOT using that stuff: I am deliberately sacrificing some security for usability.

The reasons for -all- that complicated keyservers and Certificate Authority stuff are 1. The need to have public keys available for anyone who asks (we do not need that since this is 'default deny' for all except our 'friends') and 2. The need to establish authentication - 'are we actually talking to who we think we are?'.

The need for an external authentication authority is to make sure there is not a 'man in the middle' of our transaction. Specifically, in the key exchange as I suggest it, someone COULD insert themselves in between us, get both public keys from us, and impersonate each of us to the other. So I would think I was emailing you my public key, but 'spook' in the middle actually gets it, and sends you a different key, which he also has the private key for. You think you got my key, you actually got his. He now gets an email from me, decodes it since I encoded it with HIS public key, recodes it with your public key which he has but you think only I have.

Protecting against this possibility causes an immense amount of extra complexity, which is one of the things that puts people off using cryptography.

The question is, 'While theoretically possible, how likely is this in real life'. My answer to that is: not very likely, unless you are specifically targeted by someone powerful enough to insert themselves into someone elses network. Most people are using large isps now, like ATT, Verizon, and they have direct connections to each other, so in actual reality this man in the middle has to have access to these large networks in a very deep way.

Who could do this?

A hacker? Maybe briefly, for a very small number of people. To do this to EVERYONE would take immense amounts of money, and for what gain? They would be pretty quickly found out. 

Verizon itself, perhaps for commercial reasons? To sell ads? The cost equation just does not work, it takes far too many resources for too little gain.

A foreign government? Maybe in specifically targeted cases. No practical return and pretty much impossible to do for everyone, there are simply far too many resoures needed, too much exposure, it would surely be found out quickly. 

Your own government? Most of what they do is more in the line of 'taps' to get information than man in the middle (with possible exception of https, in some situations). It does take a lot of resources, even for a govenment. But this has another problem in the case of email: it is very likely to be found out.

In the MITM setup I described above, remember that the man in the middle is fooling both sides by giving them the wrong keys. So what happens if you take your cell phone with you on vacation (to Russia, Brazil, Hong Kong, a place with a very small isp in the country...) and use another network to connect? Well, that network had better be MITM'd too , because if it is not, you and your friend will not be able to read each others email, because you both do not have each others keys, you have the man in the middle's keys. You will know by this that you are compromised.

This is also defeated by exchanging keys manually, or even by something so easy as checking through another channel, for example, call up your friend and tell him to start reading what he thinks is your public key out loud. It had better match what you see...

It makes little sense for a government to try to MITM every single possible path for every single person, in every possible circumstance, something that is not practically possible, to do something so easily found out, and of limited value.

Even if I went the other way, and forced everyone to use a complex system, buy personal certificates from a CA, what would be gained? Apparently they have the private keys of the CAs already, and can still game this.
Key-signing by multiple people as used for pgp still useful, and still can be used as desired. 

One thing I left out of the key exchange is that of course, while the initial emails are not encrypted, they should still be signed, and by the 'private' private key which can be later checked after the friend has obtained it. That may help some.

What the user gains from this is ease of use, less spam, privacy protection from most bad actors reading your mail, and protection from generic, automated, mass 'fishing expeditions' of the type that create a lot of false positives - so you don't get put on a 'watch list' for talking about pressure cookers. Or a couple actors for talking about 'making a bomb' after watching 'The Producers'.

This is all about 'reasonable privacy' not 'perfect security'. It is like deciding to have a private conversation with someone by walking outside your house. Yes, someone COULD be using a parbolic microphone from a half mile away to pick it up and record it. Still, I see no need to build a solid concrete soundproof blockhouse just to keep old Aunt Biddie from being shocked by what the young folk are talking about.

-Mike

---

From: Leo Vegoda <[email-masked]>
Date: Tue, 15 Oct 2013 17:37:54 -0700

On Mon, Oct 14, 2013 at 04:09:06PM -0700, Mike Demmers wrote:

[...]

> They get backed up when they back up their system.

You seem to have ignored the word "securely" in that sentence. And
anyway, most people don't backup their systems at all. 

[...]

> I need to be very clear about what I am doing here by NOT using that stuff: I am deliberately sacrificing some security for usability.

I found it hard to distinguish between your thoughts about user
interface design and your ideas for a protocol. Frankly, I'd wait
for a strong protocol design before thinking about UI elements.

Have you considered documenting your thoughts in a less
conversational style?

Leo

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Oct 2013 02:09:31 +0100

> Have you considered documenting your thoughts in a less

Good suggestion. And there's time before the I-D
cutoff too. [1]

S.

[1] https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88

---

From: Mike Demmers <[email-masked]>
Date: Tue, 15 Oct 2013 19:54:23 -0700

On Wed, 16 Oct 2013 02:09:31 +0100

> Good suggestion. And there's time before the I-D

You mean, write a draft?

I am new here...

I am only a user who really just came here out of frustration, thinking that if there was anything at all I could do to badger people to improve usablility, my main concern, I might do that. Just a consumer of RFCs, etc.

The whole default deny thing was just an offhand thought based off anothers comment. I surely didn't have any such thing in mind before that moment. I decided to just explore the idea a bit, thinking that either someone would point out a serious flaw, or if it seemed useful, someone wiser than I might possibly incorporate the idea in some improved form into something already being worked on.

At this point I don't really know if anyone else thinks this is a good idea, or a bad idea, or I am just another nutcase so out of the flow most are ignoring me. If it is the last, just say so, I am not thin skinned and will shut up about this with no rancor. ;-) 

> for a strong protocol design before thinking about UI elements.

Yes, I think I misunderstood what you were asking, as I thought to myself while writing that last exactly the same thing, that specifics like that were not really very relevant yet. Except to the degree they may shed some light on what might be required underneath.

I don't really think of this as a protocol, it is more in the nature of 'if you add this minor capability to MTAs, we could do this'.

In short form:

--

Encrypted email should be default deny, causing it to be a special case for a persons inner circle, providing anti-spam benefits, and allowing normal unencrypted mail and the many years of expected behaviors to procede just as before so as not to break important existing uses of email and encourage its use.

Add another extended command to ESMTP that allows a user agent to indicate that a message has been encrypted by it, so that state can be passed on and used further down the line to filter email, allowing a default deny mode to be used for encrypted mail. 

--

What is that? Not really a protocol, yes? Minor change to a protocol.

By the way -Steve- usually on lists there is no need to also CC people with your posts, but I noticed some here seemed to do that. I did notice sometimes the list, or at least the archive, seems a little slow. What is the norm here? 

-Mike

---

From: Mike Demmers <[email-masked]>
Date: Tue, 15 Oct 2013 20:46:20 -0700

On Tue, 15 Oct 2013 17:37:54 -0700

> anyway, most people don't backup their systems at all. 

Here is, I hope, a better answer to your question 'How are keys securely backed up' , which I now understabd better:

That is handled by the underlying program you are using to encrypt your mail, and so has nothng to do with this proposal directly - it's implementation dependent. Out of scope.

For example, here I have Claws-Mail with gnupg installed in a plugin. Gnupg stores (or Claws-Mail tells it to store) its keys in a little database, that is encrypted on disk, with a passphrase. So claws mail must have some way to access that, store keys, etc. Since that program would have to understand both 'default-deny' and whatever its interface to gnupg is, it should be able to store keys in the same way for this. And use whatever means are available to it in Claws-Mail for backup. Or on the system.

-Mike

---

From: Elijah Sparrow <[email-masked]>
Date: Tue, 15 Oct 2013 21:35:55 -0700

On 10/15/2013 08:46 PM, Mike Demmers wrote:
> On Tue, 15 Oct 2013 17:37:54 -0700 Leo Vegoda <[email-masked]>
> wrote:
> 
> Here is, I hope, a better answer to your question 'How are keys
> securely backed up' , which I now understabd better:
> 
> That is handled by the underlying program you are using to encrypt
> your mail, and so has nothng to do with this proposal directly - it's
> implementation dependent. Out of scope.

I agree that this problem is out of scope, but it is very important
nonetheless. Every time someone hits upon a bright idea to make
encrypted communication easier to use they run up against the problem of
improving key management. These schemes, however, only work if the user
has access everywhere to their list of trusted keys. Essentially, the
authenticity problem gets transformed into an availability problem, and
the availability problem is perhaps even harder.

Three different free software projects try to securely tackle the
availability problem and could form the basis for an agnostic protocol
for portable and secure data sync:

(1) Firefox Sync https://www.mozilla.org/en-US/mobile/sync/
(2) SpiderOak's Crypton https://crypton.io/
(3) LEAP's Soledad https://leap.se/en/soledad

All of these are overkill for the narrow problem of key management.
Instead, they try to tackle the general question of secure data
synchronization and backup. I think this is probably the proper approach.

Our hope with the next version of Soledad is to add federation, so that
two or more users on different providers could share a synchronized,
searchable, client encrypted database. This could be useful for all
kinds of things.

-elijah

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Oct 2013 10:16:15 -0400

The subject is not out of scope if you decide to store the private key blob
in the cloud...

That looks to me like it might be the answer in some cases. I would rather
guarantee that the blob is strongly encrypted and can't be lost than have
the user export them to a USB stick under a weak password that they chose.

Peter has an interesting collection of PKCS#12 files...

Storage on the target device is preferably in a form that does not support
or better actively resists extraction. But that is quite expensive and
difficult to do well. There are issues such as leaking the key when it is
used (power analysis) that are hard problems.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 16 Oct 2013 10:35:42 -0400

I agree that this problem is out of scope, but it is very important
nonetheless. Every time someone hits upon a bright idea to make encrypted
communication easier to use they run up against the problem of improving key
management. 

[RS> ]  +1  Thank you for pointing that out.  It's the one of the core
problems usabiligy and implementation. "We have met the enemy and it is us."

These schemes, however, only work if the user has access everywhere to their
list of trusted keys. Essentially, the authenticity problem gets transformed
into an availability problem, and the availability problem is perhaps even
harder.

Three different free software projects try to securely tackle the
availability problem and could form the basis for an agnostic protocol for
portable and secure data sync:

Our hope with the next version of Soledad is to add federation, so that two
or more users on different providers could share a synchronized, searchable,
client encrypted database. This could be useful for all kinds of things.

-elijah
_______________________________________________
perpass mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/perpass