STEED - Usable end-to-end encryption

[gnupg at lists.grepular.com]

On 25/10/11 21:11, Mark H. Wood wrote:

> So, to summarize what I think I've been hearing: the problem which
> remains to be solved (if it is a problem) is a nontechnical one, and
> no amount of technical wizardry will solve it.  The most that can be
> done now is to be ready to help someone who fears for his privacy and
> asks, "what can I do?"
> 
> Maybe someday there will be a panic and everybody will be asking.
> It's good to have an answer.

I think there are two major technical problems which would make things a
lot easier if they were solved.

1.) A system of mapping email addresses to public keys
2.) A system of distributing private keys between all of a users email
clients automatically.

These can be tackled independently.

For #2 I'd like to see an IMAP extension where the client can upload and
download password protected private keys. The security of the keys would
rely on a strong passphrase (different from the IMAP passphrase
obviously) but it would solve the problem of copying the keys between
clients/backing them up. It would also mean that the clients can handle
the key generation/management without the user even knowing it is happening.

For #1 I'd like to see two options. First of all, the DNS solution
described in the STEED proposal. Secondly, as a backup, if the DNS
record doesn't exist, and somebody emails me with a header containing a
link (*) to their key and its fingerprint, or even just the key it's
self, I'd like to automatically use that. Initially major email
providers like GMail/Hotmail wouldn't implement the DNS solution, but
that wouldn't stop people using GMail/Hotmail with supporting IMAP
clients from automatically looking up keys and encrypting.

I can imagine these two solutions being implemented natively in Dovecot,
Courier IMAP, Evolution and Thunderbird if the right people can be
convinced. Maybe a few other widely used open source IMAP servers and
MUAs. At that point, getting noticed by Microsoft/Google/Yahoo should be
easier.

Web browsers would need to be upgraded to make functions available for
webmail providers. I'd imagine this coming later once average users are
using encrypted email without even realising. Each new implementation
would simply lead to more and more encrypted email. We don't need an all
or nothing approach.

We might even end up with MSAs that accept mail from clients without
encryption support, then look up the recipients public key, and encrypt
it before passing it on.

(*) there's a nasty privacy issue when you're able to trigger a
receiving email client to do arbitrary http lookups. It means the sender
is able to determine when the recipient downloaded the email, and what
IP address they were using at the time. Perhaps MTAs could look up the
public key on delivery and add it to the email headers.

If somebody pulls this off, the spam fighting industry is going to have
a lot of fun. It becomes a lot more difficult to identify spammy content
if you can't read it. I guess all of that filtering tech (bayes/uribl
lookups etc) would end up having to be pushed to the client. Those are
problems to be solved by other people though.

-- 
Mike Cardwell https://grepular.com/  https://twitter.com/mickeyc
Professional  http://cardwellit.com/ http://linkedin.com/in/mikecardwell
PGP.mit.edu   0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20111025/bbd05ebf/attachment-0001.pgp>