LWN: Comments on "STEED: End-to-end email encryption"

STEED: End-to-end email encryption

cras — Mon, 07 Nov 2011 01:06:35 +0000

If mails are stored encrypted on server side without server knowing the private key, it also means that the server can't support server side searching of mails. Users like search..

STEED: End-to-end email encryption

dd9jn — Wed, 02 Nov 2011 08:29:12 +0000

It is not a matter of running a few keyservers. We are talking about hundreds of millions of keys. We need a reliable and scalable distributed database. DNS does just this for decades.

STEED: End-to-end email encryption

dd9jn — Wed, 02 Nov 2011 08:26:28 +0000

Revocations in OpenPGP work by updating the public key (e.g. from a keyserver). Thus the keyservers obviously support this kind of revocations - it is nothing more than an updated key. However, if you look at the response times of keyservers you will notice a delay of some seconds. This is too long for regular revocation checks. Further, most gpg frontends don't even have an easy way to generate a revocation and send it to the keyservers.

It is also impossible to remove a key from a keyserver - that is by design and we can't do anything about it. Now with DNS, it is pretty simple to remove the key. In our proposed trust model this removal is also used as an equivalent to a key revocation. Sure, anyone can simply put copies of the keys on keyservers etc - but that is not the point.

STEED: End-to-end email encryption

spaetz — Tue, 01 Nov 2011 08:10:04 +0000

> key servers don't allow for revocation? last i checked they did.

An even if they didn't that were mainly an argument to add that capability. I believe that running a few reliable key servers will be less hassle than convincing my mail provider to fudge their DNS server to provide my gpg key.

STEED: End-to-end email encryption

micah — Tue, 01 Nov 2011 00:06:16 +0000

>Another really important feature of DNS is that it allows for key revocation or rollover. Keyservers are not able to do this.

key servers don't allow for revocation? last i checked they did.

STEED: End-to-end email encryption

dd9jn — Fri, 28 Oct 2011 19:29:48 +0000

Some of the keyservers work quite well. However many of them go offline for longer periods and from time to time you will see one of the long-time keyserver to be switched-off. It is something a geek is able to manage but it needs too much knowledge. With the ~2 million keys and the low traffic we have today you may have not noticed problems. However, we aim for hundred of millions of keys.

I contrast, DNS is a replicated and well matured database with enough people knowing how to maintain the system. It just works. There is even a standard for the key storage; something we do not have for keyservers (the de-facto standard for keyservers is the latest SKS version).

Another really important feature of DNS is that it allows for key revocation or rollover. Keyservers are not able to do this.

Werner

STEED: End-to-end email encryption

njwhite — Fri, 28 Oct 2011 18:16:24 +0000

Why replace keyservers with DNS? When we already have keyservers, with keys on them, which work well. Creating a key automatically when a new mail account is set up and sharing it with a keyserver sounds great, and ssh style trust as a default option rather than the web of trust seems reasonably valid. But the DNS part is the toughest to deploy, and as far as I can see has no real benefit.

STEED: End-to-end email encryption

nybble41 — Fri, 28 Oct 2011 13:38:57 +0000

That works securely only if the password storage system itself is secure (e.g., does not run in the same account as the user's other programs) and the user is at least alerted (securely) when a program accesses the stored credentials. Otherwise any unprivileged local exploit would grant free access to all your passwords. Full-disk encryption, by itself, meets the first requirement, but not the second--once the disk is unlocked anything running in your account can read the password list.

STEED: End-to-end email encryption

josh — Fri, 28 Oct 2011 10:58:12 +0000

Passphrase management does not seem like a particularly hard problem. Users shouldn't need to have more than one password: the one which unlocks their password storage system. (In my case, that password decrypts my hard drive, and everything else follows from that.)

STEED: End-to-end email encryption

josh — Fri, 28 Oct 2011 10:56:58 +0000

Personally, I'd like to do the opposite: encrypt email to my GPG public key upon receipt, so that I can store it on my IMAP server for convenient access from a couple of devices, without leaving it on my server unencrypted.

Preventing the perfect becoming the enemy of the good

copsewood — Thu, 27 Oct 2011 19:17:14 +0000

There seems to be some useful thinking here. Requiring the user to input a secure passphrase in order to read email where they currently do not need to do this would be a backwards step. Assuming the reason for opportunistically encrypting email is to prevent it being read as plaintext in transit, having user-unfriendly defences to protect keys against compromised clients would seem to defeat the main purpose.

Better to get email encrypted by default (wherever the domain admins support this) with most users not noticing. Protecting credentials against compromised hosts in a manner which doesn't cause users to want to tear their hair out is another job, which should not be done using solutions designed just for this purpose alone.

There is a similar kind of conflict between the perfect and the good concerning the fact that the way that browsers handle self signed HTTPS certificates scares most users off, so sites which can't be bothered with the costs of certificates now of very limited security value choose to use plaintext HTTP in preference to HTTPS, because the former doesn't frighten the horses.

STEED: End-to-end email encryption

jonabbey — Thu, 27 Oct 2011 18:50:14 +0000

Well done for attempting to tackle this problem, all.

STEED: End-to-end email encryption

brinkmd — Thu, 27 Oct 2011 13:51:02 +0000

Hi,

stripping the encryption locally and storing unencrypted is fine, there is nothing standing in the way. You will want to keep signatures though (that's possible because mail is first signed then encrypted, and you only strip the outer layer), and use our trust model. You will also want to use opportunistic encryption and automatic key retrieval and distribution.

Thanks,
Marcus Brinkmann

STEED: End-to-end email encryption

Klavs — Thu, 27 Oct 2011 13:08:45 +0000

Nice idea - but I for one - would very much prefer my email being stored UNENCRYPTED on my own imap server (which may store things on an encrypted home-partition or not) - and then just access my mail using imaps and https (for webmail).

I hope they make room for that in the standard. In this way, postfix (or some other mailserver) could simply decrypt the email, if it's for local delivery - and set some markers for the MUA - to verify keys etc.

STEED: End-to-end email encryption

nmav — Thu, 27 Oct 2011 09:19:55 +0000

Very interesting idea and approach. It might be the key to turn e-mail to secure by default. Congratulations to Werner and Marcus.