893564 - Viral Encryption

Status: UNCONFIRMED

(Thunderbird :: Security, enhancement)

Description

[Thorsten Sick]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130627161625



Actual results:

One of the issues of Public Key Mail encryption seems to be that someone_else has to do some extra effort for me to get an encrypted mail.



Expected results:

To solve that, Some small improvements in the applications would change the workflow and make encryption "viral".
1) If I created a key, the mail header of my mails contain a flag indicating I want encrypted mail with a specific key
2) If someone elses Thunderbird receives a mail with that header, it offers the user to install engimail
3) On installation there is the option for that user to create a own key ("Two of you friends encrypt. Do you also want to do that ?")
4) My key is downloaded from a public key server
5) The address book gets the marker that I want encrypted messages (with the given key)
6) Now all communication between me and my friend is encrypted without extra work on the other side

This can spread. If my friend now uses encryption he also infects others :-)

Goals is to reduce extra work on the other side that sends me encypted mail that I want.

I very well know that the key is not verified yet. That is another issue.

All that is already discussed in Engimail. See:

http://sourceforge.net/p/enigmail/bugs/151/

And in the mozilla.dev.apps.thunderbird

Comment 1

[Thorsten Sick]

Hi

I wrote a POC add-on.

https://github.com/Thorsten-Sick/viral_encryption

Comment 2

[raoul bhatia]

One thought (in reference to the mailing list thread): Maybe it would help to start with validating GPG signatures first and expand to full encryption later?

Comment 3

[Joshua Cranmer [:jcranmer]]

In general, we prefer that bug reports are tailored to specific issues rather than catch-alls.

Personally, I would like to say the following here:
1. I would very much like to see much easier crypto bootstrapping. S/MIME might actually be easier here, since we could easily do a partnership with some CA to basically bootstrap the certificate process (kind of like how we have partnerships for account provisioning). I'm concerned that UX for PGP's trust model is liable to be difficult.

2. The ability to decrypt is not universal among email clients, and is notably lacking among webmail clients. The Web Crypto working group may help ameliorate this problem, but I've had some heated discussions in the past about this, so I wouldn't assume that this is an easily-solved problem.

3. Our encryption defaults are too coarse-grained right now.

I've pointed dveditz (whose ability to discuss this from a security perspective is far better than mine) to this bug, and he may have more comments on this than I do. In short, I'm cautiously optimistic about this bug, but I want it to have a more proper security discussion first.

Comment 4

[Thorsten Sick]

As the source of the idea I just want to stress two things:

1. The fix _only_ does the bootstrapping for crypto. The installation of Enigmail as soon as it is needed. Configuration and key exchange must be done there and are not part of the solution here. It only solves a small problem. But it solves the first one in a chain. Do not expect to much :-)

2. Please give it a good security kickin' around. If it breaks it should break before any code is released to the users

3. Please give it some good Usability kickin' around. I do not know the Thunderbird UI guidelines and installing stuff without the user's agreement is always a bit creepy.

4. If S/MIME is the way to go, we can maybe add some similar bootstrapping for the user. Nice would be something where the user just clicks once on an <OK> button and has a running crypto system.

Comment 5

[Wayne Mery (:wsmwk)]

duplicate of bug 448964 ?

Comment 6

[Kai Engert [:KaiE:]]

(In reply to Wayne Mery (:wsmwk) from comment #5)

duplicate of bug 448964 ?

No, it's just that both discuss ideas related to secure email.