Great because SMTP is completely broken. The lack of E2E encryption and sender authentication makes it completely useless these days. We're bogged down in workaround upon workaround to combat spamming/phishing and other abuse. Companies no longer rely on its security but instead just send an email to check their portals. We need something new.
However the whole slideshows/surveys should be handled in the applications. We need a good protocol first.
>The lack of E2E encryption and sender authentication makes it completely useless these days.
The elephant in the room here is that there is nothing wrong with, say, PGP. Any meaningful approach using public key crytography and crytopgraphic signatures to achieve confidentiality and authentication over SMTP ends up with the conclusion that you could of just used the OpenPGP protocol.
I think the reason we like to think that there is some new method available that will finally make things work is the hope there is a purely technological solution available. After 30 years of failing to come up with such a solution it is clear that there is no such solution possible in isolation.
PGP is incompatible with both forward secrecy and metadata secrecy.
If you only want to keep your message body confidential (or authenticated), PGP is reasonable. But it provides a strictly lesser degree of secrecy than modern e2ee messaging applications.
In fact, depending on your threat model, modern SMTP-TLS (which is not e2ee, but does provide some metadata confidentiality and forward secrecy) may in fact be an improvement over PGP.
Forward secrecy isn't really an issue with email. There are few that would be willing to delete their emails after reading them. Keeping old messages around for all practical purposes negates the value of forward secrecy. Most people like to keep their old messages in an easily accessible form so forward secrecy is not very important for messaging in general.
>...metadata secrecy...
This is not a huge problem with a medium like email where you can be more or less anonymous. Contrast with things like instant messengers that insist on a phone number.
>But it provides a strictly lesser degree of secrecy than modern e2ee messaging applications.
Most of those applications take the form of instant messengers. Since such things by necessity have to leave the private key material exposed all the time they are generally less secure than something like encrypted email where that key material can be kept very locked down.
>...modern SMTP-TLS (which is not e2ee, but does provide some metadata confidentiality and forward secrecy) may in fact be an improvement over PGP.
True enough. SMTP-TLS does provide even more security to the encrypted email user. Most importantly, it prevents passive listeners from detecting that an email was encrypted and thus worthy of further interest.
I can't help but point out that this sort of discussion is an excellent example of the state of denial that exists with respect to end to end encrypted messaging these days. Rather than addressing the broader overall issues we are quibbling about obscure technical details.
E2E with forward secrecy was not possible in the past because email was an offline thing. You can't do PFS without a live connection between the endpoints.
However, these days this should be less of an issue in an ever connected world. Nobody uses UUCP or batched SMTP anymore :)
Another thing is that e2ee breaks a number of useful features of e-mail:
- The ability to painlessly access your mail from a number of different clients, ranging from fully-featured desktop clients to smartphone apps to webmail.
- Server-side filtering (both spam and in general)
- Server-side searching (mandatory for webmail and depending on how big your mail archive is, still rather useful for smartphones, too)
Well one issue with them is that they're totally optional. The protocol should have this built in. The way it is now is a kludge. Even mails from big companies still end up in my O365 junk box. I didn't check them in detail but something failed there. At the same time the spammers are actually pretty good at avoiding spam filters.
Also, they don't really provide sender authentication. They provide sending domain->sending server verification. If you have a business that uses the same email provider, you will be able to fake sender auth if you can convince the server to send it. This is why it's a kludge.
If we'd require emails to be signed by default this issue wouldn't be present.
What I really miss these days is public protocol innovation. In the old days if a protocol stopped meeting the needs, people would go back to the drawing board and publish and agree a new RFC. These days we just tack on workarounds to old protocols without fixing the root issues, or we switch to closed alternatives (like what has happened to IM) which is even worse.
The problem is that s/mime and gpg are too complex for end users. Especially the key management, the encryption itself is not the issue.
s/mime is expensive in terms of certificates and difficult to set up. GPG's trust chain based on key signing parties has never taken off outside the crypto geek community (Don't get me wrong, I'm one too!)
Perhaps a "let's encrypt" approach to s/mime could work though. I could see that happening. It would indeed solve a lot of issues.
Corporate environments generally have an easier time with s/mime, and IIUC this app is focused on corporate environments.
GPG is nice (I like a lot and have used it for a very long time), but it's certainly niche.
That said, I included s/mime and gpg to illustrate that end to end encryption is not only possible, but that mature, functional tools are available in an SMTP+extensions environment.
It would be interesting to know how mnm/TMTP does encryption. I'd assume it uses TLS for transport. As for endpoint and server storage encryption (assuming it does that at all), you'd hope they'd use some sort of asymmetric key encryption, which raises the same issues as s/mime and gpg.
I thought SPF was more "this email is allowed to come from these hosts" authentication which tells you nothing about the sender (to me, at least) other than "they used an approved host"?
I think this is great and not great.
Great because SMTP is completely broken. The lack of E2E encryption and sender authentication makes it completely useless these days. We're bogged down in workaround upon workaround to combat spamming/phishing and other abuse. Companies no longer rely on its security but instead just send an email to check their portals. We need something new.
However the whole slideshows/surveys should be handled in the applications. We need a good protocol first.