1146728 - E-mail encryption improvements (finally for all)

Status: RESOLVED WONTFIX

(Thunderbird :: Security, defect)

Description

[u466741]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150320202338

Steps to reproduce:

S/MIME and PGP/ OpenPGP aren't used by most users!
Both either: not recognize in the security community has having good algorithms (NIST/ NSA ones... elliptic curves/ hash/ cipher, also Brainpool now in GnuPG) or use too small security margin (the best one can hope is 128 bit... in the best case possible: RSA 4096 SHA-256 in GnuPG... but RSA is already getting old, and attacks may already exist to some RSA implementations, disclosed or nor).


Actual results:

Bad implementation!
Difficult/ impossible to convince anyone to use digital sign/ encipher because they have to do more than the original configuration of the account at the mail program: 

> S/MIME: go to a web site (that they have to find...), request the digital certificate, pay (if it's not free), received the e-mail, open in the browser, install the digital certificate in the browser, export the digital certificate somewhere to the disk and use some password, import to the Thunderbird, enter the password to unlock the Thunderbird safe, password for the digital certificate it self, verify that has been correctly applied to the account... remember to use it when sending e-mail's... going every year again to the web site to start the process again... anyone can guess why 99,95% of users will refuse to do it?

> GnuPG: go to a web site (Windows: gpg4win, others probably at the GnuPG web site), download the binary, install it, go to the Enigmail web site, download the .xpi file, return to the mail program, go to extensions manager, find out that you are supposed to install that .xpi file from the small icon at the left of the search box, install extension from a file..., reboot the program, configure options if it doesn't find the GnuPG binary, create a new key for every e-mail, publish at keyserver (if it likes extra spam...) and publish at the rest of the places. Any guess why 99,95% of users will refuse to do it?


Expected results:

Thunderbird should create digital certificate that can sign and encrypt (if it has the other person key in file, should add in attachment by default) the messages by default. 

S/MIME and PGP/ GnuPG are simply not being used by the common users. Also S/MIME is using the old and insecure SHA-1 and TripleDES, GnuPG is getting better but still mandatory supporting  the insecure SHA-1 and 3DES... and as explain above is very difficult to the average user to implement

I think Thunderbird can make much better! Kind of mix between S/MIME and OpenPGP... in order for the users regain the privacy and security that it should never had lost in first place!

The idea as follow:

- User install or upgrade the Thunderbird.
- The program, when lunched, demands the creation of a new Digital Certificate for each e-mail account (or import a valid one that already exists).
- The program checks in a mozilla server if the domain name is valid, if it is, then the program sends EnScrypt hash results from the original certificate hash and e-mail address, to the server and the server sends an e-mail to the person to confirm the person has the control over the account (it can be made automatically, more on that bellow).
- After the person confirms through the link (or the program sends automatically), the server assigns an "OK" message to the requests for that e-mail with that digital certificate, to the others should respond "NOTOK" (in order not to reply if the e-mail exists unless the user already has the public key of the user, then their is nothing to "loose" and should say "OK" (the hash results from EnScrypt for the hash of the public key and of the e-mail (separately)... not the e-mail address it self, and not the public key... that parts only the user should share with those that it wants to share... this also makes the stolen of the database a none issue since it won't help in anything like getting the e-mail themselves or the public key with the e-mail. Yes, if someone haves the database can probably search for e-mails pre-computed to a list, but won't help with obtaining the public key).
- The person now haves a digital certificate that can use to sign and encrypt their messages and attachments by default.

- The server should check the domain name, and verify it's expiring date, and 2 weeks later (after the set expiring date) the Thunderbird should submit the key again to confirm is still valid. If it's set to expire in, lets say, 8 years... should check at least 1 year after the first time and then every 2 years (if still inside of time frame of the domain duration), to make sure is still used and valid. If the person doesn't activate through the link sent to the e-mail between immediately and 4 weeks period (to allow vacations) it should be removed from the database. When user begins the Thunderbird again, if it sees is not in the database, should send again the EnScrypt hash to verify again the same way the first time.
>> This verifications could be made automated! Once the mail program received the mail message would immediately activate it by recognising some special string like MOZILLA-DC-AUTHENTICATION://8450W8476W843769837S469832470D6983247
>>> The server should wipe from the database the e-mail address after successfully delivers the e-mail or the program sends it back to confirm it has received (whatever happens first)... and the data goes from the "confirmation server" to the "Verification Server" used by the Thunderbird (and maybe others?) clients to check the status of the digital certificate.

- The "Confirmation Server" should wait for the "token" for 1 week, and then delete the request. If it receives multiple requests, only the one that it receives the answer should be accept, the rest should be wiped instantly.

- The digital certificate can be update by the person at any moment if it wishes to do so, after updating the key it repeats the process, if everything goes correctly the new certificate should be the one to be considered valid by the server (this avoids previous owners of the e-mail address of keep sending e-mail's with a valid certificate verification from the server for example, or to "revoke" previous keys).

- Should be possible for the owner of the e-mail to remove the information of the server at any moment, have it been created by it self, or a previous owner of the address... should exist some web site to enter the e-mail to remove it from the database (after confirming using an e-mail link).

- The key should have a date and hour obtain from the Mozilla Server (UTC or some other pattern)... once submitted to the server it would be accepted only if it was created after the oldest key at server, otherwise the user should start the process again until it presents an newer key then the one that is already at the server.

- EnScrypt Must perform at least 2 seconds or up to 5 seconds of process intensive in order to avoid possible security problems... and to make it harder to send requests all at the same time... should also prevent some gateways... this should be for users, not corporations... although corporations can have the encryption be made at gateways, mail servers or end points if they really want... 
One of the security problems it can avoid: the e-mail should always produce the same hash that goes through the EnScrypt to make the verification of existing e-mail on the database (if it's stolen) even more time consuming for the attacker... but for the server is just see if it has (or not) the data.
The client my only notice that it takes between 2/ 5 seconds to receive the confirmation from the server for the status of the digital certificate. If request my be a problem, may be a good idea to cache the status for the session or 1 day (with the possibility to force status update).
>> To make the process less memory and bandwidth intensive, can send the information in the same query like for example: https://server11.dcverificatio.org/?=2796EF7FE360573BDFA9E5E0C06C2C0E74B39177CBBD446A8B58FEBC3ECE6A1548FCBBD418AE60020412CE11ED3615C7C0670E27C0C1AC1330A0C8DC68984685-AF9E3FC18801CC7C4CCA1FA3AEF98BA8DCC0C56BD1BCF4BF56C54CEDB6374C4D36787C1D6499B6E9EE42A8D8210E78275F00ADC141469C1762CADE2138A37B0D where the first part after "/?=" is the 512 bit hash result of the e-mail and the second part after "-" is the 512 bit hash result of the certificate, both through the EnScrypt.

- The Thunderbird should have 2 icons, 1 for indicate the public key status at the server (if it has been properly validated and is current), other 1 to indicate the trust that the user himself gives to that key.

- For the user to trust the key should be required to enter the 512 bit hash in the prompt (by clicking the icon to confirm) to verify, by comparing with the original source (Business card, website, social network, video, by phone, by (secure) chat, mail letter...), 129 ALPHANUMERICS characters. No one is forced to verify, for it to work properly, but if the person is going to confirm better to be 100% sure!

- For the server, shouldn't be necessary any login in normal circumstances.

- For the server, having account should be only for domain(s) that they can prove they own by making 3 changes:
> Some change in the DNS records (that can be made in any domain registrar, like some null dns server like: dns.verify526434.mozilla or something else that can be accepted by registry authorities);
> Insert some file like "hsudghsiudhgsiu.dcverify" in the root of the domain to prove FTP access;
> Receive an e-mail in the webmaster@domain.

This way it's reasonable to believe the person does have access to domain at all levels... should be qualified.
Then could configure to allow/ not allow any e-mail from your Digital Certificate services... or just allow for some e-mail's.
Should need to repeat the prof of ownership every time the domain is set to expire according to the public records, or every year if their isn't records. You can short cut this by allowing to stay at DNS records the verification information and at the root the verification file. If it doesn't verify again manually or automatically it should be locked and stop having real impact until it's confirmed. If anyone else claims to be the owner, and proves (by the same methods) it should be granted to the new person.

- The digital certificate it self shouldn't contain anything special (just the information of the key it self (Elliptic Curve), ID of the key (hash), the name choosen (should be able to show any character of any language properly), e-mail associate to it. If the user has several e-mails going to the same place should have different keys... since can loose access to any of them, and it's necessary to remove from the "Verification Server" in a secure fashion, that key... but not the others that are valid.
The only scheme I can remember that could allow the same master key be used for different services/ accounts is the one from SQRL of GRC, but that is just for signing the "tokens", not to also encipher/ decipher... but may be possible to do it... so that the user only needs a master private key from it derives all the keys for the several e-mails.

- The server is not absolute necessary, but would help to identify "revocations" (new keys)... once anyone sees the server error (that must specify that the current known to be good key, at the server, doesn't match the local one) the person can go to whatever other method of contact [web site, online video, social network, mail letter, phone call, personal meeting, (secure) chat... or any other way] to know what happen/ what is the new one (key).

- Should be able export/ import the private and/ or public key. Should be able to get the hash of the key to be able to copy to another place (clipboard...).

- Should be possible to export/ import everything at the same time (for/ from external storage like CD/ DVD/ BLUERAY/ USB PEN, and other...) using advanced encryption like SKEIN 256-256 and EnScrypt hashed to 512 bit (must perform the operations for at least 60 seconds to make guessing very, very difficult!).

- It should use NON-NIST chosen algorithms, since Snowed revelation their is no doubt that NSA wants: and do!!! all they can to infiltrate the standards and company's products like library's of products... to use poor random number generators, ciphers and maybe hashes...

So I suggest an all around protection of 256 bit security (could be up to 512 bit security, but I guess Mozilla (or NSA) would think to be to much...):

- Elliptic Curve: M-511 (formerly named Curve511187) or E-521 (information about both here: http://safecurves.cr.yp.to
- Cipher: Threefish 256-256 https://www.schneier.com/threefish.html
- Hash: Skein 512 (https://www.schneier.com/skein.html)
- The resulting hashes going to the server for latter consulting, for every key of every e-mail: EnScrypt (detailed page here: https://www.grc.com/sqrl/scrypt.htm and development tools that may (or may not) help: https://www.grc.com/dev/sqrl/EnScrypt/ ).

This should be enough to provide true 256 bit security at e-mail's, for free, for everyone... at least at Windows, Mac OS and Linux (maybe latter mobile platforms?)... and since its creation is mandatory by the program for all accounts and signing and encryption are enable by default (should be possible to disable, of course, manually, by rules or always unless the user explicitly enables the option)

I expect that the developers see this as a good idea and implement it.

This will also make the sending (or recovery) of passwords and other private informations (medical records, bank information, electricity utilities information, lawyer information between him and the client, messages between enterprises, and many other uses) using the e-mail potentially more secure since users can "demand" from the services for them to send that confidential information for them always encrypted and digitally signed. Of course you should suggest exactly that for this gain even more traction and starts to be the gold standard.

LETS MAKE, THIS ONLINE MAIL, SECURE AND PRIVATE, LIKE IT SHOULD BE!

Comment 1

[Kent James (:rkent)]

Thanks for the report.

You are not likely to get a significant discussion of your ideas here, because this is too big of an issue to be dealt with in a single bug. There is a lot of interest for security improvements in Thunderbird, but to actually get them done will require a significant effort to rally developers behind the cause. It is not as simple as "I expect that the developers see this as a good idea and implement it."

After Thunderbird 38 releases in May 2015, we will probably be doing discussions on priorities of the next major release on the tb-planning email list. Make sure you follow that and make appropriate comments. We'll want some ideas on what sorts of things are possible to improve security in Thunderbird.

Comment 2

[u466741]

Thanks for the reply.

The issue is big, but I have try to insert here all I could remember that would be useful to make this problem go away.

I subscribed to that mailing list, I will try to make this report notice on that list, so that "we" may finally have this poor privacy and security problem solved for a big time. They are trying to solve the https:// by making it available for everyone... this would do the same but for e-mail.

Basically (for those that will only read the comments):
- Force users to create and use this new private/ public key by default on all messages (unless he/she says it doesn't want on that message);
- The public key is confirmed by a Server to help identify true keys. But should also be confirm by the person.
- The private/ public key, cipher and hash should be safe for the years to come (at least true 256 bit of security (not key length..).


I would add, here, that to provide future resistance against Quantum attacks (if they ever became a reality...) its possible, if Mozilla Thunderbird is (or can be made) compatible with GPL license, to make it use freely the NTRU ( https://www.securityinnovation.com/products/encryption-libraries/ntru-crypto/ ) with the code (free) for OpenSource projects at github: https://github.com/NTRUOpenSourceProject/ntru-crypto
Maybe it's possible to use just NTRU or even better NTRU + M-511 for added security in digital certificate to be used that will protect the encryption... and also sign the messages. But this is just a suggestion.

Comment 3

[Wayne Mery (:wsmwk)]

We also have 
Bug 135636 - [UE] Implement "Encryption when possible" option
Bug 149876 - "require encryption" usability
Bug 893564 - Viral Encryption (including joshua's comment there)

Comment 4

[Joshua Cranmer [:jcranmer]]

I'm going to close this bug as WONTFIX, because its scope is way too big.

In particular, you seem to be intending for another format to replace S/MIME and PGP. That by itself is WONTFIX (at least, not without clear standardization efforts). The main problem isn't in the transfer format, but rather key generation and distribution, for which we already have a few bugs open.

I will also point out that Thunderbird is not GPL, and therefore it is not possible to use GPL code in Thunderbird (and even LGPL is dicey).