It's surprising to me that anyone could think that email signing was even vaguely in the ballpark of being comprehensible to the ordinary person.
It's the key exchange that's difficult. However, as the blog rightly points out, having companies sign their emails would be a massive step in the right direction. Every ordinary person uses an email service. If that email service handled the key exchange for those companies the it would be truly wonderful. It doesn't even need to be that difficult given that these companies almost certainly have certificates for their websites.
Then all the service provider has to do is put this nice message when delivering the email: "This email was not signed by the company that it claims to be sent from. Beware." Not in any way difficult for an ordinary person to understand.
With things like signal or whatsapp you get encryption and signing automatically and everybody uses it.
Why don’t people use signing with email then? Because it is not the default, not built in and not the standard everywhere. Blaming those people for it is wrong. Blame those who didn’t manage to implement the standards and stand in the way of making it the default
Signal does make a bigger deal about trying to get you to verify, but in practice for both systems casual users don't do it. Most of my Signal contacts aren't verified.
Without this step an attacker can MITM these protocols because the identity problem is hard and cannot be waved away.
I'd prefer to verify all of my contacts but, given my security model, this is good enough and a huge step up from email.
I don't need to verify the code because everything else about the communication matches.
> Turn on this setting to receive notifications when a contact's security code has changed. Your messages and calls are encrypted regardless of this setting.
Or more so, DON'T have. I don't know if I'd qualify for "ordinary person" here but regardless, of the emails I went through this morning I don't think I can think of ONE that I cared about actually being from the sender it said it was from. There are very few that matter that much.
I'm not sure how PGP would help though, as the user also has to check, if the email from his bank was signed with the correct key. Checking the exact domain name is something he can already do and I guess is also easier to understand.
https://en.wikipedia.org/wiki/Deniable_authentication etc. Perhaps you can do it with asynchronous protocols too, though it seems harder.
Well, some of the oldest corporate systems (Lotus Notes, MS Exchange) did (and I think still do) have the capability for transparent secure messaging. Still, sysadmins rarely ever bother to use it. I believe the cause is that nobody wants to operate a certificate authority if they can avoid it, and when they can't, they'd rather restrict it to the bare minimum (servers that are absolutely necessary).
If corporate sysadmins can't be bothered to look after keys, you can imagine how motivated the average user will be to do the same.
The truth is that X509 remains a clusterfuck: it's just too burdensome. LetsEncrypt is a first step in the direction of replacing it with something better and more automated. "LetsEncrypt for email" would be very welcome - although I bet the security services of the world would be really pissed off.
It's not just people are not learning. I don't see any ordinary email client is encouraging people to use signing or encryption. Which is very odd to me.
Just imagine what if all the email client start asking their user to sign their email, and mark unsigned email as "Untrustful".
I don't want this to come across the wrong way - but are you a Linux engineer/admin? I think when someone has deeply understood deeply technical things for a very long time, they lose touch with just how arcane their knowledge is and how much of a real expert they are - skyscrapers above the ordinary level of knowledge. This state leads them to think that what is obvious to them can't be hard for others to understand.
I really don't see what's so hard about the first paragraph, which is the only one intended to be understood by a layperson. Even though the concept of "signing" has a long-established and well-known non-digital meaning, which nearly everyone will understand, the paragraph still goes out of its way to define it. Seems pretty idiot proof to me.
There are many problems with email. The ability for l33thacker101@evil.h4x0rz.club to claim to be innocent.grandma@grandmas.knitting.club is not at the top of the list.
Heck, even on desktop clients it's a pain in the ass. Ever tried to create, install, and use an S/MIME certificate in a major desktop client, like Outlook or Apple Mail? It's ridiculous. An obscure mix of trying to use the right browser, export the certificate in the right format, sometimes even convert it on the command line, use the right mail client extension, etc.
So it's the tools that are the main problem.
Until S/MIME or similar is built into major webmail clients, and certificate creation and installation is simple on the desktop, it's never going to happen.
The people you see in tech support are not representative for the entire population.
This is like working in a hospital and coming to the conclusion that most people in the world have a serious illness.
I can imagine the average person replying 'yes there is there's the from box in the email'.
Belief is a thorny issue when trying to communicate to the masses, though.
This is like "we shouldn't use locks because some people often lose their keys".
That's what you don't seem to comprehend. Yes, for you this seems obvious. But really, to the average Joe/Jill, this idea that you could get an email from the address you expect but it has been spoofed is gibberish.
Let alone am I going to try getting her to use PGP and sign her emails.
This is hilarious. Do you have parents and/or grandparents?
Have you not had to repeatedly explain the simplest things over and over again? User names and passwords are hard enough, and you're expecting most people to understand email signing?
What experience do you base this expectation on?
Hardly. The first paragraph is easy to understand -- you tell them that "there's no proof it came from you" and that "its easy to fake emails" and that signing the emails digitally helps prevent that. Everyone can understand "there's no proof it comes from you" and "fake emails" follows on from that. Everyone knows what a physical signature is and how it helps identify that something was written by you and can imagine the concept of a digital one, even if they have no idea about the mechanics of one.
That goes a long way to describe at least why you would want to digitally sign emails, even if it doesn't tell you anything about how it works.
Would that be of interest to anyone other than myself?
Putting a stress on the "qualified developer" part would critical. We are so used to not understanding things (new frameworks every week, new code base to grok, stuff we wrote 3 weeks ago that is just spaghetti), that I think it won't be representative of how most people would enter a subject.
I saw this when looking at other people learning languages, where some of them had a "I don't understand anything" reaction and just stop there, because it's just not a normal situation to them ('growing up' was part of securing that comfort zone for a lot of people)
Also if someone who normally sends you a signed message sends you an unsigned one, a security warning is displayed and / or the message is automatically directed straight to the spam folder.
from: support@apple-support.example.org [This message was signed by apple-support.example.org (Verified by Let's Encrypt)]
Please send us your Apple ID and password for routine security checks.
Sure, maybe you're trusting a scammer more and more, but at least when you get a new email from a scammer that's trusted by millions (let's say by more than one EV cert signed the key that signed the email), then it's pretty sure you're just being scammed by Apple to further their regular bottom line.
For example, ask someone the following question. You have cards with letters on one side and numbers on the other. Cards with vowels must have odd numbers on the reverse. If you have cards [A B C 1 2 3], which cards do you need to turn over to check that the rule is followed?
It's easier for people to understand when you rephrase the question as: we're serving sodas and beers to restaurant patrons of various ages. If I have [Beer Soda Water age40 age10 age30], which patrons/drinks do I need to check? People will have a much easier time answering [Beer age10] than [A 2].
I would try explaining it to people with a real world analogy: did the mail-bombs [0] to Soros, Obama, Clinton, and CNN come from Debbie Wasserman Schultz? People can write anything in the return address and mail a package from a public mailbox. Email acts the same way by default. Do you think non-IT people will have trouble understanding that analogy? (or that the analogy doesn't represent the situation correctly?)
[0] https://www.wired.com/story/mail-bomb-scares-misinformation-...
You don't need people to understand why digital signatures work to explain to them what they do.
So, if signing were properly featured, then the failing emails would get burried in Spam folder, even more, the email client could block the 'Click here so I could screw you' links in such emails, and more choices how to integrate it in common user's flow.
However, the other question is rather if the email signing would still serve the purpose in case when the system/server gets compromized, keys stolen. Did any major company paid off fully what's due for losing away scores of users' private details?
The errosion of trust may be more detrimental to Joes and Jills outhere.
The absolutely terrible concept of a modal dialog is a different topic, but it is quite common nonetheless.
Reminds me of yesterday: https://news.ycombinator.com/item?id=19357573
That has not been my experience signing anything. I cant judge about the math behind the encryption, but the interface side of things has always seemed ... lacking.
Use PGP for this. No, now it is called GPG instead. We thought it was funny. Pass this optional command line argument if you want extra security. Why would we want that as a default?. Enter a passphrase - it is recommended! Except no one uses them. Or they do. Have you installed gpg-agent? Ok so you have a public key now. Before you send stuff to this person you should celebrate a Key ceremony with them and interchange keys physically. Now add your key to your program. Ok so your commits are signed using your key now. If you want to sign a tag, however, you will need to pass this extra flag when creating the tag.
To be fair, that last one is mostly git CLI being consistently inconsistent [1]. But it still another spoke on the wheels.
Encryption needs to be easy in order to be mainstream. Otherwise it will be relegated to the minority which can jump through its interface hoops.
[1] Yes, I am going to be eaten by a hobgoblin any second now http://stevelosh.com/blog/2013/04/git-koans/#the-hobgoblin
How do you know that's your bank's signature and not from "h-s-b-c.com"
How does granny know?
Exactly. Any solution you can come up with for baking PGP authentication into email can be applied also to DMARC, so if your primary use case is authenticating reputable businesses why not back the tech that's already seeing adoption by said businesses?
Obviously it'd be great if all digital messages were effectively authenticated using strong cryptography. I imagine at some point we'll get there, probably through a combination of maturing technology and better educated users.
On the other hand there is nothing existing today for telling your MTA to trust this or that domain only. There is no standard so every provider would start by doing their own thing. That missing part is the difficult part, and that is only doable in pgp today.
However it is true that in both cases there should be some UI indication to ask you "do you trust this domain ?"
That's just the tip of the iceberg in difficulty.
There's also:
0 - understanding the web of trust
1 - verifying that the key you exchanged actually belongs to the person/entity it purports to be from (ie. verifying identities of keyholders and verifying key fingerprints over an out-of-band communications channel).
2 - keeping your own secret keys secure
3 - making and keeping offline backups of your keys
4 - understanding why, how, and when to issue and use key revocations
But it's still plenty hard to ensure that we don't show an email as validated as definitely being from amazorn.com, along with some other funny business that could be pulled.
It does tend to get the problem down to an already existing set of problems, though. It could also be the "killer app" for GPG emails.
The user doesn't need to understand any of this. The user does not need to sign his emails. He just needs a mail software that can handle signatures from well known organizations, and can warn you when the signature doesn't match. Just like my browser puts a green or red symbol when there's a problem with the certificate.
Everything you list is mostly orthogonal to the submission.
What makes an organization "well-known" enough to be on this list? What happens if an organization is not on this list? What if I'm a completely-legitimate (S-Corp paperwork filed!) organization called amazorn.com?
And what problem does this solve that the current DMARC system does not?
Lets email servers and domain owners attest that a message was sent by them. For instance, gmail can apply a DKIM to all outbound emails, to verify that it's sent by gmail, and that they authenticated the person that it was sent as. For example, here's one of gmail's DKIM public keys:
k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviPGBk4ZB64UfSqWyAicdR7lodhytae+EYRQVtKDhM+1mXjEqRtP/pDT3sBhazkmA48n2k5NJUyMEoO8nc2r6sUA+/Dom5jRBZp6qDKJOwjJ5R/OpHamlRG+YRJQqRtqEgSiJWG7h7efGYWmh4URhFM9k9+rmG/CwCgwx7Et+c8OMlngaLl04/bPmfpjdEyLWyNimk761CX6KymzYiRDNz1MOJOJ7OzFaS4PFbVLn0m5mf0HVNtBpPwWuCNvaFVflUYxEyblbB6h/oWOPGbzoSgtRA47SHV53SwZjIsVpbq4LxUW9IxAEwYzGcSgZ4n5Q8X8TndowsDUzoccPFGhdwIDAQAB
Organization signing would be a whole different thing. Something like Extended Validation for SSL/TLS.
I'm with you, purely for selfish reasons. The first thing I do when I suspect phishing is look in the raw email source for the DKIM signature.
It would be trivial to expose the DKIM signature in the UI. Things like whether the signature was good, what domain(s) signed the email, and what was signed would be very handy.
There, conceptually it's explained, to anyone who has any concept of what "writing" is.
(Also I wonder if using the word "signature" only makes it harder to explain. Like, trying to explain to someone how an analog signature proves your identity. Because, well, it doesn't.)
It also neatly explains the concept of key sharing, which seems to present some pedagogical difficulty for some reason - you can sign your letters all you want, but if I've never seen your signature before then it doesn't actually prove anything.
Public key = knowing what your signature looks like
Private key = the muscle memory required to create a signature
By now every single email user with an email address that has been exposed to the internet has received untold amounts of spam emails with their own address spoofed as the sender. The only question is if they've ever noticed it.
This wouldn't pass most spam filters today, thanks to stuff like DKIM: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
But I agree that this is rather intransparent for the user. What we need is a warning like "You have never received an email from this domain. Do you want to trust it?" and something like the Extended Validation Certificate for companies (does something like this already exist?). Not PGP though.
But they are right in one sense: it's their mail provider's job to provide the signing infrastructure.
But customers have to know they need it and demand it
"Just as it's easy to fake regular mail, but it's never been a real issue for anyone. You don't really see me notarizing every mail I sent, do you?"
Isn't this what DKIM was supposed to be?
https://addons.thunderbird.net/thunderbird/addon/dkim-verifi...
There is a sister standard to DKIM called DMARC that lets a domain publish instructions for what to do if unsigned emails are received. It can run in allow, report and deny mode. Report is useful, it asks the recipient to send it back to the domain which is helpful for large networks that may have many people and services sending mail on their behalf.
You can use this tool to compare gmail.com (ignore failed signatures) vs google.com (reject)
https://dmarcian.com/dmarc-inspector/
Thus google.com i.e. Google employee / service email is protected from From header forgery, but consumer Gmail isn't (too many people sending mail from non-Google SMTP servers).
So, can they still my signature without me even knowing? Wouldn't that make it worse for the recipients, then, getting signed messages that give them a false sense of security?
And what is this PGP thing? PGP Keychain?
Hey, I updated my computer and I made a new key, and I can't read the encrypted messages they sent me anymore.
The problem for the layman user though is that PayPals.com (fraudulent) can also sign their emails -- and they'd be conditioned to equate "signed = legit" (and can easily miss misspells, alternative domains, etc).
And I'm not even sure it would work: many users would just click the "yes I know them, please trust" button on first use.
An alternative would have "unknown" be a little, not very scary warning (with easy TOFU), and the "this handle looks like this other one, they may be trying to scam you" blinking red warning. Then it would be on the developers to detect typos and look alikes.
The user-visible part of this is very limited. Remember, no one is expected to sign their own emails: just verify that the signature is correct (which the software will do). It's not that different from verifying a handwritten signature.
HTTPS is notoriously difficult for users to understand. Most people don't even know what a server is. At least with emails you have analogies to do with sending paper letters to letterboxes that map pretty well.
I think the big push for HTTPS from the last few years is in part because Google claim they now give you an SEO benefit from it, HTTP2 (i.e. for better performance) requires it and Google + Firefox show more scary user visible warnings than they used to for non-HTTPS sites.
That's because it's entirely up to site operators (and browser/os vendors to add trusted registries) and not to the user.
If it was to the end user to install something and manage certs for https, it wouldn't work at all...
I don't sign my emails, and I don't expect my contacts to sign their emails. I also don't see how the effort would bring a proper "return on investment". It would basically change nothing for me or my contacts.
This is an infrastructural problem, and needs to be solved at that level. The user has nothing to do with it, doesn't understand it, doesn't know what problem it solves.
So I Googled how to make it happen for GMail. The options seem to be some browser plugins, or switching to another service.
It is not handled by Google at all.
That's a non-starter then, because I access my GMail account from the app some of the time, and there's no point in "some of the time security".
Once GMail supports something like this, it'll take off a lot faster.
If your mail server receives an email that claims to be from paypal.com, but it's not dkim signed (by paypal.com) it should be rejected.
But even paypal.com, likely one of the top phisher targets publishes their DKIM signature with: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.paypal.com;
I'm surprised that even internal email systems inside of companies regularly accept email from allegedly inside the company, that are forgeries. You'd think ibm.com (just an example) would A) sign ALL outgoing email B) check DKIM for all incoming email C) reject anything claiming ibm.com, but without the ibm.com signature.
Seems insane that it's so easy to send email as a companies/organizations management.
What you want to look at is their DMARC record:
v=DMARC1; p=reject; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com
That's quite a contrast to Thunderbird with Enigma which really feels just like a UI for gpg.
They would get accustomed to seeing green checkmarks on emails coming from big businesses, and then possibly notice their absence on phishing emails.