Regarding why gmail doesn't have signing support - you've got 2 options really. Signing on the client side, where gmail doesn't know about the encryption and you have to provide your own browser extension which does it - this is already available. And signing on the server side, which probably nobody ever wants to do, because it means handing over your private keys to gmail.
When I get an email from my bank why doesn't it have any sort of authentication so I know it is from my bank and not someone pretending to be my bank.
It probably does, but the mechanisms are directed at MTAs and not displayed to end-users.
http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
http://en.wikipedia.org/wiki/Sender_Policy_Framework
They're the reason all the phishing spam that looks like it's from your bank ends up effectively spam filtered, while real mail from your bank makes it to you. All of the top 10 US banks have SPF/DKIM set up.
I get stuff from "PayPal" all the time... None of which are from PayPal.
Why can't I get a little lock icon like I have in my browser with the name of the signing party? What really is the barrier for something like this? Why do we demand this for outgoing connections to these institutions through our browser but not for inbound communications like email?
I can't find any examples now, but I swear I've seen gmail say "Verified Sender" or something to that extent on some random messages I've received before. I don't know if that was due to domain keys or something else..
This would still only be signing; I agree it'd be better if e-mail was more commonly encrypted.
mta transfer encryption probably needs more uptake and plugging of simple degradation attacks that cause transfers to flow unencrypted - in my opinion having providers do this for us is a losing battle.
But considering S/MIME is likely the lowest acceptable form of email authenticity, why don't we have an interest in progressing the adoption of this technology?
You should be able to create a separate gmail-specific certificate and give gmail only the key for that.
The resistance in doing this sort of thing bothers me. There are users who believe that their keys should only be on an airgapped machine or on a hardware crypto token or something. This is fine for things that need ultra-level security, but at the same time the gap between usability and ultra-security prevents adoption of even the simplest signing.
If instead we consider hosted mail providers to have a copy of private keys as acceptable, incremental improvement in security (but on the understanding that this is a weak mode), use of strong encryption would become more ubiquitous and the ones who need stronger security would be in a position to get it.
To make this work, I think that maybe we need more metadata capability though. Certificates should explain the level of security/usability trade-off the subject expects to take with the corresponding key (everyday use, ultra protected but awkward, etc). And protocols need better support for multiple keys that match a particular identity (eg. "sending encrypted? Do you want to send it to the recipients everyday key, or his ultra-protected key but then may not bother to read it for a while because it'll take him effort to get access?")
Of course, this also means that there is a UX problem to solve. But that's part of the problem with email cryptography, isn't it?
Interesting... could this really just be a UX problem? Why do we understand HTTPS without problem? Or am I naive in believing HTTPS is widely understood by the layman?
On the other hand, the server administrators have to contract with a CA, get certificates, configure everything correctly, consider browser compatibility, etc.
Email must be two way. Suddenly _every user_ has to do what HTTPS server administrators do. And then they have to convey the intent of a signature or the availability of an encryption key to their correspondents.
I think this is what inherently makes email cryptography much more complicated from a UX perspective.
Assume for a moment the bank actually wants to email its customers (and leave confidentiality aside). That means the bank will want its customers to trust the signature on the email.
Which means that the bank will want the email client to have an appropriate public key to verify the email signature. Regardless of whether we assume the email client is a browser or desktop app, this is where we enter the world of hurt, the world of wasted money.
For this to work perfectly, the user has to have one or a small number of public keys installed - otherwise, their email client will quite happily validate signatures from dozens and hundreds of sources - and how will the user, who has no skill or knowledge in this area, know whether or not the right public key is being used for signature validation?
To get to the point where the user doesn't have to make this decision, the number of public keys installed has to be very low, perhaps one, that is, the bank's very own certification authority certificate.
What if the user's machine is compromised and another certificate installed? After all, there are thousands, hundreds of thousands of Windows machines in zombie botnets, how do we know the bank's customers are not among them?
Hmm, I guess we need multiple layers of security on those machines. All to protect the root key store.
Hmm, starting to look an enterprise desktop: Controlled by central IT, not by the user.
I'm being fast, superficial, and a little glib in this, but please do think through this from end to end, and be as ruthless as you can in your thinking.
PKI works. But only in controlled enterprise environments. In those environments, it works reasonably well. At ongoing expense, sometimes high.
Outside those environments, there are simply too many places to inject sufficient doubt so as to invalidate any quantifiable risk assumptions.
Which is why email as a consumer service delivery channel is pretty much dead. No control over the consumer endpoint means no assurance that anything there is what it seems.
If you cannot control that endpoint, you cannot ask the user at that endpoint to trust you, because you cannot trust that what you sent there is actually what the user sees, nor can you trust that what the user sees is what you sent.
But I do think there is be a big incentive to validate an email sender... Reasons are many and the climate should support it
1. Increased public awareness of privacy threat 2. Institutions build their business on trust 3. Fraud risks are huge, institutions have some skin in that game and some incentive to reduce that threat