Conceptually it's not hard at all. "When you send an email there is no proof that it came from you. It is easy to fake emails. When you press this button, it will 'digitally sign' the email. Now people can tell that it comes from you."
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.
I get what signing is — but to the ordinary person it solves a problem they didn’t even knew they had. When you explain it like you did my first question would be why emails are not signed automatically if it is just about the press of a button?
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
In either Signal or WhatsApp you have no verification whatsoever of the true sender unless you meet them out of band (preferably in person) and compare codes that summarise the public key identity value.
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.
Most of my signal contracts are also unverified (my nerd friends are). However, I am notified if their key changes, so unless our connection was MITM'd on first contact, I would at least have a warning and know to be more suspicious. Usually I'll follow up with people out of band to verify that they got a new phone or something. This happens infrequently enough that it is not a hardship.
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.
All of my Signal/Telegram/WhatsApp contacts are unverified in the app itself, but almost all of them are de facto verified by other means; we plan meeting up at bars and I know who I'm chatting with because the person I expect shows up. Or we send emails or communications via other means and the conversations match.
I don't need to verify the code because everything else about the communication matches.
You need to enable security notifications, and you will be notified of key changes.
> 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.
I don't use Whatsapp, so I don't actually have first-hand knowledge. Now that I think about it, it may be that I was told that it automatically regenerates the key more often than they need to, which would have the same effect.
I don't believe this is true. Every time I've asked about a key change, it has been because someone either got a new phone, reinstalled the app, or reset their phone.
> but to the ordinary person it solves a problem they didn’t even knew they had.
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.
This has already been touched on in the article and the comments. DKIM isn't any good when it tells you that the email from fraudulent mybankk.com is verified just because the phishers were clever enough to set up DKIM on their site.
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.
One difference is that Signal and Whatsapp are synchronous so they are able to use deniable authentication. That's in contrast with asynchronous email where signing a message can then be proven to have come from the sender to a third party - not always desirable.
> Blame those who didn’t manage to implement the standards and stand in the way of making it the default
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.
> I get what signing is — but to the ordinary person it solves a problem they didn’t even knew they had.
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".
This is a deeply ironic reply - is it intended to be? There's almost no words there that would gel into comprehension in any way for average Joe and Jill.
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.
You must have a very low opinion of average Joe/Jill, to not expect them to understand "When you send an email there is no proof that it came from you."
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.
It's actually much worse than you expect. Most email clients don't show the email address of the sender; they show the display name. If you get an email from "The President <l33thacker101@evil.h4x0rz.club>", most users will see that the email comes "The President." And l33thacker101@evil.h4x0rz.club could get a valid signature for her domain, because she obviously controls it, and people would see that the email from "The President" really did come from "The President."
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.
Why do so many email clients do this? In my opinion, it only makes things more confusing. It's especially irritating when a contact has multiple email addresses (work/personal) and it's not obvious which is which.
And you must not work in tech support. But all this is irrelevant for the most part because aside from understanding WHY it's useful and important, there's the fact that most people are using web clients, and trying to, say, sign or verify a message in GMail is pretty much an unclimbable mountain for the vast majority of people.
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.
"What do you mean there's no proof it came from me, it says <name>@gmail.com right there in the sender address! What do you mean the sender address can be spoofed? Headers? What's that."
...and then you tell them that it's exactly like someone writing a fake return address on a piece of mail before sending it to you, and they understand, because as stated above, this is conceptually very simple. You don't need to talk about "headers" at all - I don't know why you're bringing them up.
Exactly. And now imagine you manage in some way to explain average user that he cannot trust email sender. Then explain him that if email is signed then it is OK. He will most probably answer "why the hell now should I trust email sender !? There is just a dumb icon saying the email is signed. I do not trust it !!!". Which would just be the most sane reaction actually
It's not a case of not understanding, it's a case of not believing. If you're talking to a lay person that trusts you, they may raise such an objection, but they'll believe you once you reply "that can be, and often is, faked".
Belief is a thorny issue when trying to communicate to the masses, though.
I don't know if you're replying to the wrong person, but I'm not arguing we shouldn't use anything. I'm answering 'will they understand' and my opinion is 'no'.
haha, I don't think you understand. If I told my dad "There is no proof that an email that came from me, came from me." He's going to say... "but it came from <myname>@gmail.com"
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.
And you really think you couldn't explain that to him? There's a large difference between what people intuitively expect and what they can understand if told about it. Envelope analogies can go surprisingly far. (Assuming they believe you. If they think you can't be trusted about such things, then that's a problem of course)
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?
> There's almost no words there that would gel into comprehension in any way for average Joe and Jill.
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.
Interesting subject. I am now considering whether to do a video set "JT learns X", where a qualified developer (me) takes a subject I know nothing about, and video my learning, and see all the "well, this makes no sense" -> "how could I even have misunderstood that, it's so simple" moments.
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)
From a UX perspective, it is exactly the same as a verified user on Twitter or whatever. Some people get a blue tick by their name in their emails.
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.
No. Do it OpenSSH style. At first every identity is unknown. Then you get a mail signed by a key tied to an identity (on whatever keybase), then as you email each other your trust grows.
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.
I think that depends on how you explain it. It's hard for people to understand problems in environments they're unused to.
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?)
The first paragraph clearly glosses over a lot of details, and a bit more explanation would be required for practical use, but "almost no words there that would gel into comprehension", really?
You don't need people to understand why digital signatures work to explain to them what they do.
Joe and Jill are fairly efficient in keeping their scopes narrow on usability.
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.
These are the people who get stuck on a piece of software because a modal dialog is displayed, but they don't acknowledge it and keep trying to click on the controls in the background.
The absolutely terrible concept of a modal dialog is a different topic, but it is quite common nonetheless.
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.
You don't need to encrypt or sign anything. Organisations who email you like your bank and Paypal need to. You just need your email client to show a tick when it has verified a signature, which many already do with S/MIME.
Your email client should show you if you have encountered that identity (identities of course can and should rotate keys, etc, and identities should be also signed by the keys that correspond to the certs signed by the CAs for the website/service). At first you don't know much about it, but it's a signal. If you continue to bank with HSBC and you get emails from them, you'll be able to spot a fake and the email client can say that it's a likely fake. No need to say anything else when you can't say otherwise.
Isn't this what DMARC is supposed to give us? Big companies like my bank and paypal run their own domains so they can use SPF/DKIM to authenticate their communications (and TLS to protect them in transit). Individually signed emails are only really useful for individuals.
No, because SPF/DKIM/DMARC only says that the mail server at bank.com did send this email. What I want to know as a recipient is if it was the correct bank.com, and not baank.com. Because baank.com can also have SPF/DKIM/DMARC.
If you don't bother to check the sender then you're not using pgp the way it's supposed to. pgp wants you to assign trust to identities, explicitly or not, after which pgp will automatically tell you whether you're talking to the right person or not. That's something SPF/DKIM/DMARC doesn't have for a very simple and legitimate reason: it's not a technical issue, it's a people's issue.
> ...it's not a technical issue, it's a people's issue.
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.
Saying "I trust you" is baked in in pgp. There's no such thing for DMARC because that's not its goal: DMARC and co are on the sender side for it to say "look it's really me", but that's not what we want. What we want would be a way to instruct our MTA to say "I trust these guys, the others go to the trash/spam"
I feel like we're talking past each other here. There's no reason an MTA couldn't allow you to designate the senders you trust and send the rest to spam. You could do the same by integrating PGP. The key exchange problem is the same, but DMARC handles this by tying the key to the domain. So if the email comes from bank.com and bank.com is also where you do your online banking you can be reasonably confident your bank sent the message. If we used PGP to do this then your bank would have to publish their public key somewhere and you would have to manually check that it's valid (served over https? printed on a card handed to you by the bank manager?) and configure it into your email client. This is exactly the user experience nightmare that causes "no one signing their emails". Obviously this sort of verification is required if you want truly authenticated communications with individuals, many of whom may share a domain, but if you simply want to verify that the organization you're talking to is who they say they are then the domain name is a suitable proxy.
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 ?"
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
For this specific task, we can collapse a lot of that on the web. Adding a gpg key ring or some other suitable structure to the .well-known URL list [1] wouldn't be that big a deal. This is easier than solving the problem of securing all emails. For verifying signatures you don't need any keys of your own, so 2 & 3 are irrelevant, and the .well-known URL can have revocations in it too.
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.
Do you need to understand any of that for SSL on the Web? What the person is proposing is comparable (albeit only in one direction).
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.
SSL on the web verifies that the sender is who they've verified to a third party that they are. It does not verify that they're trustworthy in any way, shape, or form.
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:
If you get email from a domain that uses DKIM (you can use DMARC to tell), then you can reject that email if it's not signed, or if the signature is invalid. Companies can set this up on their mail servers, so it just works for every email client effortlessly.
DKIM can verify the domain, but most email scams are already done from cousin domains, which DKIM doesn't solve... and will happily report as valid, providing the scammers have set it up on their domain.
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.
I think even conceptually it's hard. Your email address is your proof. You have to use a password to access it so it must mean only you can send emails with it.
I think the difference is people can envision how someone can write a fake sender on snail mail but they can't envision how it's done on email -- they need to log in first, after all.
(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.)
An analog signature does "prove" your identity. Not very well, of course - the amount of effort to forge it is much less than a digital signature - but that's a question of degree, not kind. They are still easier to verify than they are to forge. I think the metaphor is very useful.
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
What you are saying, put into more provocative words: email world be safer now if, from the beginning, every email client had a big, friendly button "send from different address". In the years of earthly mass adaption it would have been colloquially called "the Bill Gates button". It certainly would not be hard to explain the value of signatures in that timeline.
Well I don't know if it would be safer per se... I imagine you'd probably want some USPIS enforcement for that to happen, otherwise it might end up like phone calls (given it seems people understand caller IDs are spoofable and yet it's as big a problem now as it's ever been). But yes, it could've made it potentially easier to explain.
> they can't envision how it's done on email -- they need to log in first, after all
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.
Probably not, if they use any decent email provider 99% of spam gets correctly filtered and you never really see it unless you look in the spam folder, which most people don't anyway. Also, I don't think I ever received an email with the sender as one of my email addresses.
Not really. I get a steady stream of replies to me from ignorant users who reply to "Joe job" spam, as do everyone I know. It's the most common way someone thinks "I've been hacked" when they get the fallout from one of these "Joe jobs"
My email client (geary) makes it pretty easy to add and send from aliases. If I ever need to explain this to someone, I'll keep a demonstration of this in mind :)
But if I can get a domain that looks almost like yours and send an email from there, what good is DKIM then unless someone's paying real close attention?
Your new domain will look suspicious to any bigger spam filter (e.g. Gmail's) and therefore you have to be really careful with the content of your email so that it gets through.
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.
A lot of people would still fall for that too unfortunately. And ultimately people don't know that you can even do that. They see as authenticating oneself as proving their identity.
To some extent this is happening, although not on the level of individual email addresses, rather it's the domains that are now checked (where possible), and services like Gmail warn when an email seems to come from a different origin.
In regular mail there are multiple clues of the sender's identity besides the literal content of the message: paper, graphics, handwriting (or typeface), signature, etc.
Yes. But my guess is that even wrong/no signatures will land in your inbox.
For Thunderbird there is an addon which will show you the validity of DKIM signatures
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)
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).
It's worth noting that ignore/report is for the email server it's destined for. The server is supposed to send reports back to google (mailauth-reports@google.com specifically) about the failures and such.
But it can work for individual addresses as well. For instance, gmail uses DKIM. If they only DKIM sign an email if the user is logged in as the address they are trying to send as, then boom, DKIM is proof that the email from is not forged, and the only way to bypass it is to hack the account.
>Conceptually it's not hard at all. "When you send an email there is no proof that it came from you. It is easy to fake emails. When you press this button, it will 'digitally sign' the email. Now people can tell that it comes from you."
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.
This is not about encryption, only signing. When PayPal or your bank or another large organisation send you an email it should be signed. Then you can verify it is from them. Encryption would be a nice to have, but, while it uses the same technology, it's a whole different can of worms.
>When PayPal or your bank or another large organisation send you an email it should be signed. Then you can verify it is from them.
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).
I see only one way around that, and it's prohibitively expensive: have the user assign aliases to public key signatures, and mark everything else with a big scary "UNKNOWN".
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.
Actually it proves even less than that --- it proves that it's someone with access to the domain that it was sent from. And if that's not amazon.com, but instead amazon-account-services.ru, then DKIM will happily report that the message is valid.
First, I generally prefer if people do not have a proof that I sent the email. Second, I'd be worried that someone stole my private keys and impersonated me in those cases when signing makes sense. Endpoint security is almost nonexistent with current PCs, no matter how hard you try to harden your system. In the end, the risk of being impersonated for malicious purposes outweighs the advantages of signing.
Proof is good for you, as it protects you from friendly recipients from following instructions that hurt you from imposters. If you want to deny your own actual actions to an unfriendly recipient, refusing to sign your emails won't help. It's not symmetric.
Almost no one comprehends https either. Yet it seems to work well enough to protect people.
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.
> Almost no one comprehends https either. Yet it seems to work well enough to protect people.
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.
Private use? yeah, not so great with the current state of software for it. Company environments: that's what sysadmins are for. You see the occasional company where everything is signed with S/MIME.
That's sadly why I had to stop inline quoting and use the retarded bottom quoting style. Some readers actually stopped showing my message at all because they "cleverly" hid the very quote that their own program puts there. Microsoft have done so much damage to email and made it worse for everyone.
Even for programmers like me it makes no sense (to use it, not to comprehend ;)).
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.
Agreed, seems like people are just too scared to reject potentially broken email.
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.
Relaxed in DKIM allows for non signficant changes in headers (ex case of the header names, extraneous whitespace, line folding) and for changes in trailing whitespace in the body. Headers and body are configured separately, but relaxed/relaxed ends up being fairly necessary.
Which says they'd like servers to reject mail unless it passes SPF or DKIM. (There's no way to say it should pass both, although I guess if your SPF record was -all, you would need to pass DKIM)
Actually there are some solutions which work almost automagically. For instance if you combine Apple Mail with GPGTools. By default it signs your messages.
That's quite a contrast to Thunderbird with Enigma which really feels just like a UI for gpg.
A similar argument could be made for the implementation of HTTPS a few years ago. The goal should be to empower trusted software to inform a user. In the case of HTTPS, that trusted software is your browser, in the case of signed emails, that trusted software is your email provider.
It's in the ballpark. "It's a second email password so that no one can listen in on your emails". The problem is implementation. Even one where your client / provider knew the private key is better than cleartext everywhere.
It's probably easier than learning how to drive, it's just that nobody does learn it. We have a huge problem with people not actually learning to use technology. Almost everyone you meet can barely type properly.
I think if Gmail decided to implement email signing today as a prominent feature where they show a big warning for all non-signed emails the user demand for it would happen pretty quick e.g.
WARNING: You cannot trust this email was sent from who it
says it's from, the email have been modified in transit,
and the email may have been read by hackers in transit
Similar to how Chrome started showing non-HTTPS sites as "Not secure".
Encryption and signing are different things here. Encryption in this case means that the contents of the email are encrypted between Google's servers and the recipient's servers. i.e. preventing snooping.
Signing verifies that the contents of the email itself have been authenticated by the author. I.e. prevent spoofing.
All I can say is OMG yes. I've been meaning to write the exact same blog post. How is it we're at 2019 and email clients don't demand some kind of signature? How is it that you can spoof email... simply by entering the fields however you want to? It's insane.
I agree that the key exchange is difficult, but seriously I'll even take a CA if it means that I can reasonably tell that email that appears to come from my bank probably comes from my bank. Even better if a technical user can manage the keys themselves, but at least lets do the bare minimum!
PGP isn't demanded, but a different kind of signature is increasingly demanded: DKIM. Only a minority uses it to reject mail on its own (although I guess that minority is bigger than the number of PGP users), it's widely used as part of a scoring system.
>All I can say is OMG yes. I've been meaning to write the exact same blog post. How is it we're at 2019 and email clients don't demand some kind of signature?
So that you have a false sense of security when the keys have been stolen from a clueless user you correspond with?
For different people, there are different problems with email. For me, signing is less of an issue, but e2e privacy is: but so much meta data is leaked through headers that there's little point.
Then there's the issue of web of trust which signing requires to be of use, which leaks (/publicises) email addresses in adding security. Its current implementation is utterly unusable for a-technical people (like my mum).
For me, I'd prefer my server to be the arbitrator for signatures, which is a little like dkim anyway. Strong spf settings (-all rather than ~all) fixes a lot of spoofing like your bank example.
It's a problem that I'd dearly loved to see fixed up though... but how? To move onto a better email system we need to keep everyone's use cases intact: some like pop, some imap, some would prefer direct messages instead. Personally, I'd like imap with a touch of direct messaging. So, how do you handle all the handshaking between 4 devices, while maintaining absolute privacy and assurances that nothing has been tampered, but nothing can be leaked?
Hopefully better minds come up with a great solution, because all the ideas I've had are flawed in one way or another! (I've been thinking of writing an article on my thoughts...)
BECAUSE THE USER EXPERIENCE IS SO HORRIBLE EVEN FOR TECH PEOPLE
I don't know how many times this has to be repeated. I have a government mandated encryption key on a smart card and even with that PKI (it's really good), email encryption is not doable with most e-mail clients, the functionality just isn't there. Add that and we'll speak why it might still not be happening. Oh, and don't forget that when an encryption key expires my e-mails shouldn't get lost :D
Sure an email from Paypal.com can be signed or encrypted, but so can an identical one from Paypa1.com. How are users more protected in this case? In fact a big "sender verified" message in the email client for the latter email will cause a lot more phishing.
Web browsers already implement a ‘near miss that’s probably intentionally confusing” check on domains, and the code is readily extracted and shared (I know about it because someone extracted it and added it to Emacs a couple years ago).
This seems like one of those cases where more large infrastructure people need to say “don’t let the perfect be the enemy of the good”.
For Emacs (and its web browsers, email clients, etc) this comes up in a concept of “confusables” strings that could easily be mistaken for other strings, usually as a result of Unicode tricks (multiple similar code points from different scripts, or composed versus combined characters, or sometimes ugly tricks with LtR/RtL markers. The code added to emacs was. A library that could be used to detect these probably-misleading tricks, but they didn’t implement a policy for them. The uses I saw of the library fell into the sort of “Danger, Will Robinson! This looks like it might be malicious” type warnings that can be found in most browsers these days.
Also, people could have something like "sort emails from myverifiedbank.com into "Bank" folder" and then fake emails from notsoverifiedbank.com will end up elsewhere.
Much like you might have a bookmark for https://www.myverifiedbank.com in your browser, and you'd have HSTS and so on to prevent you from randomly ending up on notsoverifiedbank.com servers instead.
Email is already generally signed and verified when sent and received by competent email providers.
DKIM and DMAC are the technologies that do this. DKIM employs asymmetric cryptography to sign all outbound emails from a domain name using a key for which the public part is published in the domain’s DNS. Receiving mail servers validate signatures automatically, looking up each domain’s public key from DNS.
DMARC allows senders to advertise the fact that all email they send will be authenticated, such as with DKIM or SPF, so that receivers may drop anything else (kind of like HSTS for websites). Messages that lack a DKIM signature, from sending domains that require it, will simply be dropped.
Quality email providers, including most webmail providers, offer these capabilities built in. These technologies are table stakes for email, like HTTPS is for websites. Take a look at received email in your mailbox for DKIM/DMARC status headers and you might find that many messages are protected by these technologies.
However, even strong authentication of email addresses is not enough to prevent abuse. Attackers can send email from addresses that are similar (but not identical) to the person they want to impersonate (typo-similar domains). An attacker can fully set up the domain and employ DKIM+DMARC. Just like with TLS, possessing a key is not by itself an indicator of trustworthiness. Signing our email won’t stop people from being tricked by impersonators unfortunately.
It’s similar to the phone system: if someone calls you and claims to be an employee of your bank, how do you know if it’s really them? The best answer is often to independently navigate to the bank’s website, look up their contact info, and then use it to reach them. The same is the for email addresses: you can’t assume that an address belongs to someone - you have to verify it somehow (using an existed trusted channel). Then DKIM+DMARC can help by making it impossible for anyone to forge messages from that address.
A starting point for a better solution to the identity discovery problem could be a better address book experience, calling to the user’s attention the first time they’re communicating with a new person, especially at a new or different organization. Defending against phishing is more of a user experience design problem than a crypto engineering problem in my opinion.
DKIM and DMARC only verify the domain of the mail server ... which is something we care about only because the email clients can't do something better. A signed email identifies an individual sender. Pretty much apples and oranges.
Sure, but the SMTP server won't sign the email if it was sent with the wrong login. So unless I don't trust the whole domain (in which case even PGP could result in a false sense of security), this pretty much verifies the sender. Only thing I need to do is to check if it's correct.
There's nothing stopping spammers from signing their spam. The pain point with signing and encryption is key rotation.
One problem is that both scammers and banks themselves use domains like paypal.accepournewtos.com or paypal.usersurvey.com and paypal@ourmailservice.randomdomain.com
> There's nothing stopping spammers from signing their spam. The pain point with signing and encryption is key rotation.
Yes, but those signatures can't be verified.
I understand this is tricky problem; how do we prevent people from simply clicking "accept this unknown key"? I'm not sure; but not every user is a blubbering idiot, and "unknown signature" strikes me as a lot better UX than "carefully look for spelling errors or misleading domain names".
[Transcription: Windows XP error dialog with the yellow triangle - title "Something happened and you need to click OK to get on with things." details: "Certificate mismatch security identification administration communication intercept liliputian snotweasel foxtrot omegaforce." then you have a button saying Technical Crap and three radio buttons 1) More technical crap 2) Hoyvin-Glayvin 3) Launch photon torpedoes and then OK and Cancel buttons.]
Nope. Back in the old days Microsoft actually did tests on this in Internet Explorer, with users real banking credentials not fake ones, so that the user would properly value giving credentials away.
The only thing that actually works is brick wall UX. If you don't give the user the option to ignore the problem, they are forced to give up, which was the only safe option for them. If there's a way to continue, despite it being unsafe, users will do that.
Humans have a psychological defect in which they become rigorously focused on achieving a specific objective, and screen out indications that this is a bad idea. This is why those signs saying "Danger! Low bridge" aren't as effective as you'd expect. The human driving the over-height vehicle is focused on getting to the other side of the bridge, your warning signs aren't helping them do that, so they ignore them.
This is why a modern Firefox has brick wall UX for some HTTPS problems and would like to do it for more such problems. Only brick wall UX keeps people safe.
This is also why "bad idea" and similar Chrome overrides for their brick wall have to be changed periodically, these start a "power user" feature for people who actually do what they're doing, but quickly they spread and are used by people just trying to get things done, without grasping that now they're completely insecure.
That brick wall UX keeps me from using Firefox on my work intranet, since we have a self-signed certificate it doesn't like. I kind of wish the other browsers did the same, so they would actually fix it instead of everyone having to click the insecure warning to continue five times a day.
Maybe, but then again they get the same message every day at work when accessing their business application with outdated certificate or whatever and have been used to just bypass it ...
Because no mail client implements a sane process for acquiring and operating S/MIME certificates using an S/MIME-issuing CA within the mail client’s UX, much less doing so automatically for all configured email addresses using “confirmation link” emails occasionally.
I used to work for a big tech company and the vast majority of people there signed all email by default and encrypted them when the content was sensitive. Part of onboarding was a training session on how all this works.
Now I work for a non-tech startup and there are exactly two of us who sign our email. Happens to be another engineer I need to occasionally exchange encrypted messages with.
As a positive, at least no one seems confused by my signed messages.
> For signing there’s more margin; it’s okay if half the people never verify your signatures.
The problem that people may not verify signatures is one, but what's far worse is that bad email clients won't show the email content for emails signed with S/MIME certificates that have later expired. I was in an organization where S/MIME certificates were always issued with a validity of one year, and I used to sign all my mails. After a year, a colleague told me (and showed me) that my previous mails in Outlook couldn't be read any longer. Turns out that Outlook has a convoluted process to say "Yes, I know that the certificate used to sign this mail has now expired, but it was valid at the time of signing and I just want you to let me use it for older emails or just show me the email content with some warning". I had to go through a series of steps to make sure Outlook trusted those certificates for all mails.
Email clients need to improve a lot more on usability if people are to use signatures and also manage multiple (expired) certificates.
PGP doesn't need to be user-friendly just to verify signatures. It's like verifying your Linux distro's package system: all of them sign their packages (usually with PGP) and they get verified on installation, but as an end-user I never see it.
And yes, PGP is hard, but only if I want to add signatures to my emails, or use it for encryption. But that's a different use case than what I wrote about here. I think this is exactly the sort of confusion I intended with:
> Confusion between every-day “random person A emails random person B”-usage versus “large company with millions of users sends thousands of emails daily”-usage.
>But that's a different use case than what I wrote about here.
I find it amusing that the problem in the HN threads isn't that they know too little, it's that they know too much. They've seen arguments against PGP for years, and are having trouble processing the post in any way that is different from the "usual" PGP use cases they've seen. I'm seeing comments arguing that the user can't understand concepts of web of trust, or will get fooled by Paypals.com's signature, etc.
Keybase diverged so significantly from PGP that one wouldn't say "Keybase is PGP with good UX". You can say "Keybase is encryption with good UX" though.
> Would probably have avoided Podesta and the entire Democratic Party a lot of trouble
Unconvinced. The Podesta phishing email has:
> From: Google <no-reply@accounts.googlemail.com>
> Date: March 19, 2016 at 4:34:30 AM EDT
> To: john.podesta@gmail.com
> Subject:Sоmeоne has your passwоrd
From a Google domain, to a Google domain. Google uses DKIM, so the sender, message-id, etc, WAS ALREADY SIGNED, and apparently got through anyway.
Which part of this would further signing have helped?
Mail.app happily supports signing, and has done for like a decade - the problem is having some meaningful directory service. Basically, enterprises can often times set up internal key directories, but general publicly accessible directories are much more challenging (in a user friendly way).
[edit to add instructions:
1. If you already have a public signature you can import it into keychain, otherwise create a certificate via Keychain Access | Certificate Assistant | Create a certificate...
2. set the permissions to allow it to be trusted for signing + decrypting email (in an enterprise environment this is automated) by double clicking the certificate in keychain access, expand /trust/ and set secure mail to "always trust".
3. In the subject field of a new mail you should now see a couple of buttons, the default (I think) is for signing to be enabled -- the right button
]
I always sign my email with PGP/MIME, although I do wonder if any of the recipients ever bothered to validate the signature. I mostly do it out of habit at this point. I use my GnuPG smartcard to authenticate through SSH and encrypt files so I might as well tell mutt to sign my email.
These days I suspect that the average user simply trusts their provider's antispam to discard bogus emails (and as TFA points out, DKIM does effectively provide a signature, although obviously it's not the same trust model).
I haven't given up on PGP, if anything I use it more than ever, but in this age of webmails and the general trend towards the centralization of the web I think the author is preaching in the desert.
Author does not mention dkim in article which makes me think he might not "read all the relevant RFCs" as he claims.
Majority of important emails are signed and are not easy to spoof
> DKIM is useful, but limited. All it does is verify that an email which claims to be from paypal.com is really from paypal.com. What it lacks is the ability to show warnings such as "this email wasn't signed, do you want to trust it?" and "this signature isn't recognized, yikes!"
Perhaps such warnings could be accomplished with DKIM somehow (I'd have to study it to see), and if it can: great! But in its current state it's doing something different than what I'm proposing (which is why I omitted it originally).
I think the big issue is that not every email client reacts harshly enough to emails with either no DKIM header or mismatching DKIM signature. Today it's basically just one of several factors for marking a email as spam, when in reality it should show a big-ass red warning.
At my current job it is "mandatory" to sign your mails with mime. We got the infrastructure in place. I have seen 3 signed mails up until now. A colleague of mine got the reply to one of his signed messages "can't read because it's encrypted".
I was a period I actually sign every email I send. I stopped when I keep getting replies about there's this mysterious p7s attachment people can't open. And some people say their virus scanner thinks it's malware.
Once (or rather, if) PGP gains some traction this problem will disappear; email clients will improve the UX to show a specialised "PGP signed" box and hide the attachment.
The only organizations that i see consistently signing their emails are the large commodity traders [1], not sure what drives it (third world country operations, secrecy, etc.)
I gave up on using PGP for personal communications ages ago (even ones where signing would actually be nice and not just a waste of time), but I still appreciate services that do this. For example, my repository hosting (sourcehut, https://git.sr.ht) and related services sign emails. I could know nothing about their key, key management, levels of trust, etc. just that I hit trust the first time (I'm perfectly okay with a TOFU model here) and now I throw away any emails that don't have a green tick next to them in the "Signature" field.
Email software could make this dead simple without requiring that the user know anything about the web of trust, regardless of how complicated PGP is under the hood. For most users, even webmail users, this would be good enough.
That is exactly what autocrypt (https://autocrypt.org/) aims to do: define a protocol to effortlessly encrypt back and forth with no input from the user
Also, by guaranteeing we’re the source, it only makes us more liable for what is written. If I say something that reads like a commitment, or get upset, or tell a mistake, there’s always a chance of benefiting from a loophole during trial; if it was digitally signed, no escape.
The best interest of companies and individuals is that others send them signed mail, and that they send non-signed mail... I think that doesn’t help at all.
It’s different from signing a website, because one is way more self-conscious when putting informations on a website.
E-mail is transitioning to web based central/closed services. For example in Sweden - government do not send e-mail, instead they use a private proprietary service that require an Android or iPhone for second factor access, as an alternative to snail mail.
So if you want to keep messaging decentralized, open and standardized, instead of just complaining, we need to try out things like e-mail signing. In order to improve we need to feel the pain points and engineer them away.
I was so surprised when I received a signed email by Postfinance, my bank here in Switzerland.
I really think it would be very beneficial if all major providers would start to use that. At first not many people would check the signature, but if then this takes momentum probably all major email provider will start to show an icon telling that the email is signed and verified.
Just like Gmail shows when an email was received through a secure channel (TLS).
(I am the author of this article, looks like someone posted it here before I got the chance)
If they were, phishing would be a thing of the past; but it's not. In addition it's a lot harder to filter out targeted spear phishing with spam filters.
Spam filtering is certainly useful – as are other measures such as the malicious website list that most browsers have – but it seems to me that adding extra guarantees such as signing would be a good thing?
DKIM is useful, but also limited. It just detects forgeries of From address and such. Ideally email signing should be like https: if it's not https then you shouldn't trust it. DKIM can perhaps fill this role; but the current implementations don't; they just add some score to the spam-check.
You are begging the question by assuming that a signature on an email message proves anything useful to the recipient when the facts on the ground show this not to be the case.
It is not harder to conduct phishing with email signatures, and the fact that such phishing campaigns have no problem putting TLS certs on their phishing sites is a simple existence proof of this fact.
Email signatures does not impact spam in any significant manner beyond existing measures to prevent domain name forgery in the header. Spam email signed by joe@cheap-ray-bans.com does not stop being spam because it is signed and the signature provides no useful signal to spam filtering tools.
The difference between an email signature and a TLS cert on a web site is that in the latter case the user is making an effort to connect to a specific site and the certificate ensures that they are in fact connecting to paypaaaaal.com even if other means were used to misdirect them to this site. With email there are two problems to be addressed, transport privacy/security (a sender problem) and unsolicited email (a recipient problem) and signatures are only useful in ensuring integrity of the former and do nothing for the latter.
Okay, this may be off-topic, but I think the specific problem mentioned in the article would be much more easily solved by Queensland University of Technology providing context for the gift--which is already expected email etiquette. No need for a massive overhaul to email infrastructure. ("Off-topic" because the anecdote is a pretext for discussing signing email.)
I once had a similar experience in real-life. I received a check via express mail with no accompanying letter or explanation, which seemed like it had to be bogus. Mindful of cashier check scams, I took it to my bank to see if it was safe to cash, and they erred on the side of caution and said, "no." But it was $600, so I cashed it anyway. And then about a month later, remembered I had closed out a poker account for that same amount.
I'm all for security, but can we start with common courtesy?
The post is about signing, but the same applies to encryption:
> "This is not comprehensible to the ordinary person."
Too many moving parts, but there could be a solution. Unfortunately it's not going to happen.
The solution is that the few big webmail providers start setting up end to end encryption using any open standard. It must be the same zero configuration stuff that worked for WhatsApp which every grandpa and grandma use. If they start doing it for messages sent between their addresses, the world will follow.
Unfortunately this means that it must be done in the browser and the webmail provider can't see anything of the content. I don't think Google wants to see this happen even if they own the most used browser.
A lot of the things people suggest as replacements for SMTP could be done with SMTP if email signing became standard. You could have closed message groups where you only have emails from people you have corresponded with before. So you could have a family INBOX, a company INBOX and a friends INBOX. Getting added to a particular INBOX would involve some communication out of band. This could be done in a very intuitive way. People would have no problem understanding the concept of a private INBOX.
It would totally allow man in the middle attacks but spammers/scammers generally can not do such attacks and would not have any financial incentive anyway.
I'm guilty of not signing my emails despite associating some accounts with my key. A fear I have is signing but the receiver, even someone in the general tech field, not understanding the surrounding text/attachments and dismissing my mail. I wonder if that's part of why these large orgs don't sign.
I do agree with other comments that if big clients like Gmail abstracted PGP signing nicely for their users, it would put more pressure for organizations to publish public keys and sign lest the people they try to reach complain that Gmail gives them a nice big warning each time they try to open one of their emails.
It always surprised me that, back in the heydey of spam, few (if any) mailing lists required signatures for e-mails sent.
Most of them were subscriber-only lists, and many were targeted at a highly technical audience, new subscribers were rare, and spam was not particularly targeted.
I'm not sure how many person-hours per week was spent by moderators hand-filtering spam, and it definitely increased the delay for posts to appear.
It doesn't make as much sense today with DKIM and friends, automated spam filtering, plus the general volume of spam is lower, but seemed like such a big win back then.
My company has been a frequent target of phishing attacks. Setting up the strictest possible SPF, DKIM and DMARC records and then reminding everyone to always verify the domain matches goes a really long way to keeping people safe. It might not be as perfect as end-to-end PGP, but it's available today & supported in almost all of the major email clients. If you haven't set up DMARC yet, it's a good place to start as it stops scammers from being able to spoof emails and make them look like they came from your domain.
We, organization I work for, gave up on managing our own email. We pay Microsoft to do it. Their automated phishing detection is phenomenal. Maybe two or three emails slip through a quarter, down from dozens a month.
We had so many because our user base gets an email address which expands the email base from employees to employees + customers, so 10k to 150k+ and once someone fell for the scam it would get resent from their address which looks much more convincing.
At first thought, you'd think: All that would be needed to make this happen would be for gmail, outlook mail, and Apple's clients to support signed and/or encrypted mail and display a logo if the digital signature matches, say, a signature in your contacts.
But spammers would probably just throw a "signed" or "verified" logo or text at the bottom of the mail and fool or confuse most people into trusting an email they shouldn't trust.
We need free S/MIME certificates with decent validity periods (remember, you have to keep around all certificates you've ever used!).
Webmail (which a lot of people use) is also not ideal for dealing with certicates. You more or less have to trust the mail provider with your private keys. There are just countless attack vectors.
Finally, it's quite technical to get a certificate, copy it to all your devices that have an email client and configure them.
I am not intimately familiar with the finances of PayPal, Google, Facebook, or Amazon.com, but I suspect they may be able to afford an S/MIME certificate. Perhaps even two or three!
> Webmail (which a lot of people use) is also not ideal for dealing with certicates. You more or less have to trust the mail provider with your private keys. There are just countless attack vectors.
You are already trusting the email provider with everything. What's so bad with trusting them to verify a signature, too?
We're not communicating state secrets over encrypted email here; we're just verifying the signature on "PayPal sent you a message, click here to view it"-kind of emails.
But the signature doesn't tell you the sender is the org they claim to be, because how would the verification system know who the sender says they are?
In my country anyone can get a free certificate from the Royal Mint. But few people uses them for email due to lack of support from webmail providers, as you say.
I have been using S/MIME for over a decade. I used PGP a long time ago, but it was way too much to expect others to use. Now that S/MIME is built into major MUAs, it makes more sense.
But one problem I have run into recently is that some correspondents complain that the attached smime.p7s file causes their system to mark my messages as spam. It has made me reconsider using it.
One reason is a trusted PKI. Even if an email is signed, how does one verify the ownership of the key? I hope certificate authorities aren't the answer here, we've all seen how that worked for the web.
This is where a PKI on a blockchain makes sense.
Product Pitch: Signed emails, with inbuilt verification of key ownership, backed by a PKI on the blockchain
Estonia provides everyone a smartcard with a per-person certificates on it, those could absolutely be used to exchange encrypted e-mails in general, but the reason they aren't is because e-mail clients do not support it, there isn't a single e-mail client that comes even remotely close to that functionality. People resort to encrypted containers ASICE and attach those.
Product Pitch: letsencrypt for s/mime, would solve soo many problems. Every mailing provider could acquire a certificate for you and automatically sign it without any user interaction.
SPF can be a massive hassle since it's based on which server is sending emails, rather than which organisation is sending emails. Change some server and your SPF breaks. In a large organisations there can be a bunch of different ways of sending emails (main app uses SendGrid, marketing team uses SureyMonkey, some 3rdparty tool uses something else, etc.) In practice, I see administrators get SPF wrong all the time, which is why it's rare to see a hard-reject policy.
In addition, the limitations of DKIM also apply to SPF:
> DKIM is useful, but limited. All it does is verify that an email which claims to be from paypal.com is really from paypal.com. What it lacks is the ability to show warnings such as “this email wasn’t signed, do you want to trust it?” and “this signature isn’t recognized, yikes!”
> What it lacks is the ability to show warnings such as “this email wasn’t signed, do you want to trust it?” and “this signature isn’t recognized, yikes!”
I do PGP sign my emails but not the mails that my little web app sends out. I should try that and see how users do react.
How's the state at the receiving side? I mean what percentage of users would be displayed a message about the PGP signature being valid despite them neither using nor knowing about PGP?
I don't think there are many clients which support PGP out-of-the-box. The state of S/MIME is better though; I believe many desktop email clients already support it by default.
Still, more work needs to be done. It's a bit of a catch-22: no one is signing their emails because client support isn't that good, and client support isn't improving because no one is signing emails.
Because it adds nothing. Unless both part exchange their keys securely and both parties store the keys securely you are just delegating identification to a different infrastructure with no indication of it being more secure but with an added false sense of security with is even more dangerous.
No. You need a CA certificate that is authorized to sign email certificates to sign the email certificate that signs emails. The domain certificate is merely authorized for the SSL connection itself, and the CA that signs it likely doesn't have trust bits for email either.
Either this is true and the CA system for HTTPS is (as you say) a false sense of security.
Or it’s not true because we implicitly trust key signers; unless you’re talking about PGP only, which only has a web-of-trust model and a very poor usability track record. If that’s the case you should look at S/MIME which is very similar in its model to what we currently use for securing websites.
That site really is stripe.ian.sh like the certificate says.
It really is for Stripe, a real US company.
That the US (and every other county we care about) intentionally lets crooks run companies in order to defraud the general populace is a problem you could try taking up with your government. Although in the US that's currently led by a career grifter and a bunch of crooks so your message may not get through.
But the Web PKI did everything it could here, don't blame us.
Maybe one reason is because it is a hassle to check the signature of someone you didn't have already in your contact list ?
How do you know it's not a fake signature ? Certainly you have to look at their website and find the key. But what if this person doesn't have a website ?
for S/MIME you don't need this; it's just a CA chain like HTTPS (for better or worse).
For PGP I mentioned some possible options:
> PGP could also be used; we can bypass much of the key exchange dilemma by just shipping email clients with keys for large organisations (PayPal, Google, etc.); like browsers do with some certificates. Or publish the keys on a DNS record. Even just publishing them on your website (or, if you’re a bank, in local branches etc.) so people can manually add them to their keyrings is a lot better than not signing anything at all!
In lieu of signing, shouldn't links in emails be disabled wholesale at the enterprise/organization level? If we can't prove who it comes from, then you shouldn't click on it, end of story.
And if example.com is a decent email provider, this also proves that it was sent by john, because otherwise the SMTP server wouldn't sign the outgoing email with a wrong login.
Weird, the email says Queensland University of Technology but the author talks about The University of Queensland. Two different universities but they are close (physically) to each other.
I wish Microsoft released the patents protecting SPFv2, it could help against quite a lot of spam but it can't be implemented by GPLv3 software, it's a pity.
I always thought the best webmail would be one that uses PGP in purely browser side javascript with an open source 3rd party library, or you can disable that and do it manually if you are still worried. The fact gmail never integrated PGP shows what a fraud google is.
