Hacker News Reader

Comment by mikekchar | Hacker News Reader

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.

View on HN

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.

None of that ensures you have message privacy. If you haven't verified the key, you have no assurance that the connection hasn't been MITM'd.

What's worse is that Whatsapp doesn't tell you if they changed the key, so there is no protection against MITM.

WhatsApp used to. Did they stop?

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.

It's a setting which is off by default.

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.

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

If your bank is any good, it doesn't send you emails about your account activity or problems. Yet, it could, if everybody was signing their emails.

It already could using DKIM: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

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.

That's true. I guess we need something like https://en.wikipedia.org/wiki/Extended_Validation_Certificat... for email then.

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.

My bank and broker send an email or text telling me to log in and check the "secure email" system on the bank's site.

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.

https://en.wikipedia.org/wiki/Deniable_authentication etc. Perhaps you can do it with asynchronous protocols too, though it seems harder.

How do you explain locks to someone who's never had their shit stolen?

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

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

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.

> are you a Linux engineer/admin?

Reminds me of yesterday: https://news.ycombinator.com/item?id=19357573

also known as "curse of knowledge". See https://en.wikipedia.org/wiki/Curse_of_knowledge

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?

This could be interesting.

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.

>exactly the same as a verified user on Twitter

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.

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.

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.

> When you send an email there is no proof that it came from you.

I can imagine the average person replying 'yes there is there's the from box in the email'.

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.

Just because some users don't know what they're doing means all users are idiots.

This is like "we shouldn't use locks because some people often lose their keys".

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

Frankly I do not. My own mother tries her hardest, but I can't stop her from using variants of "Iam${X}.123" for her bank passwords and etc.

Let alone am I going to try getting her to use PGP and sign her emails.

Where X = (e.g.) bankofamerica? Or X = mother's name? Either way, yikes.

I knew a smart guy that believed someone could physically watch him through his monitor.

Given laptop webcam placement these days, this is kinda true...

I was looking at (budget) desktop monitors the other day, and noticed a disturbing number of them included a built-in webcam.

TEMPEST but to the max

And?

As an example of people not understanding the tech around them.

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

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

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

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.

> And you must not work in tech support.

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.

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.

> I really don't see what's so hard

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?

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)

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.

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

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.

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?)

[0] https://www.wired.com/story/mail-bomb-scares-misinformation-...

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.

> When you press this button,

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

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.

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.

How is this any different than a PGP signature? If you don't bother to check the sender then it doesn't matter how encrypted or signed the message is.

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.

I do agree that trusting the domain instead of the exact user is more than enough in the case of the article. What I'm saying is that PGP has the whole trusting thing built-in. Key distribution can be done through DNS (there is an OPENPGPKEY record: https://tools.ietf.org/html/rfc7929) or through HTTP (https://tools.ietf.org/id/draft-koch-openpgp-webkey-service-...).

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 ?"

"verified a signature"

How do you know that's your bank's signature and not from "h-s-b-c.com"

How does granny know?

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.

"It's the key exchange that's difficult."

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

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?

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.

[1]: https://tools.ietf.org/html/rfc5785

This is a thing: DKIM.

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

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.

BIMI is... sort of what you're looking for. https://authindicators.github.io/rfc-brand-indicators-for-me...

> This is a thing: DKIM.

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 can write your name as the sender on a physical letter and send it, and I can do the same thing with an email.

There, conceptually it's explained, to anyone who has any concept of what "writing" is.

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

> 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"

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.

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 :)

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

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.

Authentication does prove identity, to their mail service, not to the recipient.

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

> and I can do the same thing with an email.

This wouldn't pass most spam filters today, thanks to stuff like DKIM: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

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.

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.

> It is easy to fake emails.

"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?"

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.

Email has similar clues. Either way, unsolicited mail is always suspicious, in both forms.

> However, as the blog rightly points out, having companies sign their emails would be a massive step in the right direction.

Isn't this what DKIM was supposed to be?

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

https://addons.thunderbird.net/thunderbird/addon/dkim-verifi...

"It depends"

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

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.

DKIM is for an entire domain, not individual addresses, though.

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.

Sure, but why would the SMTP server sign an email with the wrong login?

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

paypals.com's signature would likely not be in any of the online keyrings my mail program is supposed to query.

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.

We already have DKIM which does exactly what you describe.

DKIM proves that it's someone with access to your domain, not you specifically.

Yes, and this is in line with the article we are commenting, which talks mostly about authentifying the sending organisations and not individuals.

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.

Reply on news.ycombinator.com