Update README.md

[MSalmanN]

Added a new web-mail provider: Mailfence. The written piece has been derived from their blog (blog.mailfence.com), my experience as a user (that spans to 8 months now) and the conversation I had with their support department.

Any further investigation of the made claims will be welcomed.

Regards,
M Salman

[elijh]

Thanks for the details, very useful. I have one question about this part:

They don't have any US based company involved in their SSL certification chain and host their servers locally in Brussels-Belgium

Why would their SSL chain matter? This would only be a benefit if they used HPKP to pin to a particular CA, which they don't.

[MSalmanN]

Why would their SSL chain matter? This would only be a benefit if they used HPKP to pin to a particular CA, which they don't.

They tend to believe that non-US based services are not prone to US gag-orders and NSL's - which was the prime reason of lavabit's shutdown, and emphasize on the strictness of 'European Online Privacy and Data Retention laws', which again as per their stance are more fairer than of US.

Besides, thanks for notifying the HPKP factor - I guess it can easily be achieved on 'leaf level' with a robust backup solution for the backup pins. However, I'll pass on this matter to the Mailfence team.

Regards,
M Salman

[elijh]

They tend to believe that non-US based services are not prone to US gag-orders and NSL's - which was the prime reason of lavabit's shutdown, and emphasize on the strictness of 'European Online Privacy and Data Retention laws', which again as per their stance are more fairer than of US.

Understood, but the problem with CAs is that every CA in the world is trusted, so it doesn't matter if you use a CA in the EU, all the clients are still trusting CAs in the US, unless you have HPKP set.

[elijh]

This seems good to merge, although I am unclear on this part:

The server never sees the user's passphrase (encrypted via AES256 and iterated, salted string-to-key specifier)

I take this to mean that stuff stored on the server is encrypted using AES, and that the key for the AES encryption is generated from the passphrase using a string-to-key specifier, or what outside of openpgp is just called a KDF.

This does not relate at all to how the passphrase is kept from the server, however, since the user still needs to authenticate with the server before they can start the process of decrypting their secrets they have stashed there.

[MSalmanN]

Understood, but the problem with CAs is that every CA in the world is trusted, so it doesn't matter if you use a CA in the EU, all the clients are still trusting CAs in the US, unless you have HPKP set.

A general perspective (IMO) is the ability of NSA/CIA to compel US CAs to generate phony certificates, with of course a requisite gag order - whereas the CA is bound to not even disclose such intrusion to media/or general public. Given that, I agree with the importance of HPKP in any case.

I take this to mean that stuff stored on the server is encrypted using AES, and that the key for the AES encrypted is generated from the passphrase using a string-to-key specifier, or what outside of openpgp is just called a KDF.

Yes, your conceived analogy is correct - and can be further verified from this blogpost of Mailfence.

Thanks for taking your time and merging the pull request.