

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

Why is it that we don&#x27;t have better support for signing email? You&#x27;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&#x27;t they?
======
viraptor
"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.

~~~
rlpb
> ...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?

~~~
rubyfan
> 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?

~~~
rlpb
HTTPS is one way, which makes it easier for users. The UX for the user is
(relatively) easy, even if it still has issues: check the URL bar.

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.

------
PeterWhittaker
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.

~~~
rubyfan
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

