Quoted from the linked Tutanota blog post below:
I wonder how this will work with something like gmail. You can’t so easily data mine every email if it is E2EE.
I wonder how this will work with any web-based mail service.
Still, they are making the right noises.
Good laws don’t force others to do good things, they punish those who do bad things. So, I hope this is about forbidding government, ISPs, etc from preventing users from encrypting their stuff.
“Obviously”, I can’t read the actual proposed German law (in German) but the vibe seems to be that it will force the service provider to offer E2EE (where it’s possible) but not force anyone to use E2EE. So maybe that is somewhere between those two possibilities.
In my country the battle would then be about the default. Does E2EE default to enabled and you have to take explicit action to turn it off? v. Does E2EE default to disabled and you have to take explicit action to turn it on?
If anyone but the users control the certs, E2E is a misnomer. Sort of like a US DoD CAC. The CAC-holder controls the PIN to the CAC, which contains a copy of the private key, but the DoD also has the private key and so can easily decrypt any message sent by a DoD user. Bill Clinton tried to force the same scheme on all US citizens as a prerequisite for internet access… and failed (thank God).
That’s why I asked about a web-based service, where it could easily be that the “secret” information needs to be applied by the web site at the receiving end.
The blog article itself is not very long, but here is a relevant quote:
Contrast it to the other side of the pond:
End-to-end encryption is being threatened across the world instead of protected. Germany is being proactive in this regard, whereas other countries are not prioritizing it as a fundamental right.
I wonder if maybe there is a confusion with the term E2EE, which has been used recently by BigTech as a mean for more “privacy-washing”; due to increasingly bad reputation of their services.
As I understand it, E2EE only guarantees that the data is strongly encrypted while in transit on the public internet. But this doesn’t mean that the data is not decrypted and scraped once received by the provider of the service: in fact, it always is; as they own the keys and need to feed their data farms with this precious data in order to monetize it. So they would make us believe that customers of their services have a “gain in privacy” with this implementation of E2EE. But this doesn’t change the business model, which is to mine our gold for profit.
As a matter of fact, the article precisely states that:
The draft law pushes for strong end-to-end encryption to guarantee the secrecy of communication: “It is an essential contribution to guaranteeing the fundamental rights to telecommunications secrecy and the confidentiality and integrity of information technology systems and to cybersecurity”
The wording is clear: it only protects telecommunication secrecy, confidentiality and integrity.
For me, the term E2EE with Zero Knowledge is the more appropriate one we would like to see and this is not at all what BigTech intend to implement!
This German law doesn’t change anything in practice since E2EE is common practice anyway nowadays except maybe for some shady low-end providers that still send in clear.
Here are some whitepapers for you, along with another blog article:
This is the opposite of what End to End Encryption is supposed to mean; with E2EE, the encryption and decryption happen at each end, eg the sender and receiver of messages. No decryption happening at rest, only the sender and recipients (in the case of communication) are able to read the contents.
What Big Tech has been doing however is being gatekeepers of the keys used to encrypt and decrypt. Therefore, while it’s still end to end, they could at any moment invisibly get a hold of the keys or even better invisibly add additional “ends” and you’d be none the wiser.
This is also why a lot of people are wary of services like Proton, since they key handling is done in JavaScript code sent to you by their servers. It could be totally different tomorrow than today if you are targeted for example… and you’d never know.
I imagine the “wherever it is technically possible” caveat will be doing a lot of work when this law is applied to email. The proliferation of different endpoint software configurations in email that mean end-to-end encryption is often not possible without manually coordinating with the recipient.
People have legitimate conflicts of opinion about how to perform email encryption, what it should achieve and in what way. Are we just opportunistically encrypting messages in transit with the attitude that any encryption is better than none at all, or are we also creating a whole digital identity for ourselves that can be held to a high standard of trust? What, if any, third parties do we trust to help us achieve this? Do we want to publish our identity to the world so that everyone can verify it, or do we want to keep it between us and our contacts?
App-based encrypted messaging services tend to get around these problems by making all the decisions for you. Everyone is on the same page because the service provider opened the book for them (to stretch an analogy). These services also have the advantage of being able to design their own protocols for distributing keys in a manner that respects privacy by default.
I suppose this is more about making sure the capability is there than it is about making sure that every message is encrypted, but it’s difficult to see what capabilities and configurations should be supported in order to please all parties. Existing secure email services tend to get around this issue by being opinionated about the best way to do things and sticking to a particular philosophy, which can end up limiting which people you are able to exchange encrypted emails with.
Great questions. I suspect the IETF will be a keystone in determining email encryption standardization.
S/MIME was documented by IETF 26 years ago (RFC 2311, March 1998) although it has been updated several times since then with the latest that I saw being RFC 8551 (April 2019).
Of course S/MIME isn’t the only standard for E2EE email and that’s the beauty of standards, there are so many to choose from.
PGP also has a number of RFCs.
The key aspect is, as the last couple of posts said: what is the endpoint and who controls it?