Ask HN: Why don't companies sign email the way we do with HTTPS?

https://news.ycombinator.com/item?id=9098079

by rubyfan • 11 years ago

8 11 11 years ago

news.ycombinator.com

Why is it that we don't have better support for signing email? You'd think banks and other financial institutions would be pushing to spread this type of technology in email clients, especially in web clients like Gmail... Why aren't they?

viraptor• 11 years ago

"banks and other financial institutions" don't use Gmail. They already have email signing and verification in outlook / ms exchange and it's using s/mime and their internal certificate chain. Same applies to pretty much any corporation outside of finance.

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.

rubyfan5• 11 years ago

I get they don't use gmail for their own email... I'm thinking more about s/mime and really why aren't companies emailing their account holders with signed email.

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.

dangrossman• 11 years ago

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.

rlpb2• 11 years ago

...because it means handing over your private keys to gmail.

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?

rubyfan5• 11 years ago

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?

PeterWhittaker• 11 years ago

You have to ask yourself a key (no pun intended) question: Why would a bank sign an email?

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.

rubyfan5• 11 years ago

Sure these are lots of logistic issues but in reality a consortium of financial institutions could push some of the big players in email to build in support S/MIME which seems similar enough to HTTPS (not that this is the gold standard but a good start).

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

Ask HN: Why don't companies sign email the way we do with HTTPS?

Related Stories