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

From: Tobias Gondrom <[email-masked]>
Date: Sun, 27 Oct 2013 20:47:14 +0000

First, I like Mike's idea in principle.

I still see one interesting problem with this (and have no idea how to
solve it):
The widespread use case of zero-footprint clients, aka webmail:
if you have no client / your client is a browser window for webmail, you
have to upload your private key to the server (and must store it there).
I.e. you would upload your private key to Google and other mail
providers. And a part of PRISM was/is to deploy direct access points on
these servers in the first place. With the access to all webmail servers
and through this to all private keys there, PRISM would at the same time
also retain full access to emails received on full-clients. So while
this might help us against spam, we might in the end not be much better
off against pervasive state-driven surveillance. Or am I missing something?

Best regards, Tobias

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

> 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.

[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:

(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
_______________________________________________
perpass mailing list
perpass at ietf.org
https://www.ietf.org/mailman/listinfo/perpass

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 28 Oct 2013 01:15:56 +0100

>off against pervasive state-driven surveillance. Or am I missing something?

It is of course possible to keep the keys on the client and it would
also be possible to develop new web browser features to keep certain
data unknowable to the site you are visiting, with some limitations. 

Acme Inc would of course still take your keys to help you synchronise
them across devices, or as backup, or to use them as another factor
in new multi-factor authentication schemes, or simply because they've
been ordered to do so. Perhaps through the DRM system where it would
be hard to notice, or the surveillance software that ostensibly makes
sure we are unable to cheat in browser games (that's coming, right?)
-- 
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: Mon, 28 Oct 2013 02:50:55 -0700

On Sun, 27 Oct 2013 20:47:14 +0000
Tobias Gondrom <[email-masked]> wrote:

The draft I am working on does not really cover this. It is very specifically about making encrypted email practical in a general sense concerning solving the 'encrypted email cannot be spam filtered' and similar problems, regardless of the underlying methods.

The webmail problem may not be such a big problem, I am not sure about this but my impression, despite the high webmail use for these large services, is that very large numbers of emails, perhaps the majority, are still not from webmail. That many or most people may have a webmail account, but it is not their _only_ account, they still typically have mail service through their isp using a more traditional MUA - and that is likely what would be used for emails where privacy is desired. I'd like to see the real numbers on this ratio. 

Even when webmail is used, however, the browser is running on your own computer. So it seems likely to me that something like a browser plugin could encode/decode the body of your emails in the browser input area or viewing area before it is sent or after it is received. The keys could then still be on the local machine. And the remote service (and associated spy agency) would see only an encrypted email body.

-Mike