IETF group proposes better SMTP hardening to secure email. At last Simple Mail Transfer Protocol (SMTP), that staple of e-mail communications, was born in an era when nobody thought the Internet needed security. While extensions have been written since to fix this – the most important is STARTTLS – there remains a problem: STARTTLS doesn't yet guarantee either message confidentiality or proof …
Noting that "our" is the third party selected by the providers of the server software to the providers of the email service who your recipient is currently using, quite possibly not even by choice, the way service ownership and users get traded around. And not necessarily in the right order.
SMTP has its imperfections but until people decide what's going to replace it they need to stop with all the half-arsed brain-farts that keep being blurted out in the hope that some large provider will pick it up and it can be the next giant leap without spotting the slight problem that they all depend on adding a(nother) third party into Alice and Bob's conversation.
Your scenario is only for those who rely on a third party email service. Whoever requires this level of security should run its own mail server associated with a correct certificate for the mail domain, and the sender as well.
I wouldn't rely on it for gmail/hotmailyahoo addresses. Nor you should trust it when relaying your mail through your ISP SMTP server. As far as I understand, this can work for direct delivery between SMTP servers which both you "trust".
> this can work for direct delivery between SMTP servers which both you "trust".
If you can establish that trust without having to pull in a third party at all, then so much the better!
Unfortunately the number of 'potentially trustable' servers continues to fall while fewer and fewer people think they are capable of running one after being hypnotised by the shiny apps and plumping for something in the cloud.
While its all well and good to see encryption in transit improved the more urgent need might be to get something like PGP baked into the protocols
As things stand one can get an email purporting to be from manager@mybank.co.uk & only by drilling down into the headers does one discover that it's from marketroid@brainfartsrus.com or scum@scamsrus.ru. Most recipients don't have the skills for this even if they've got the time to check every email. The protocol needs the receiver to be able to go to the purported source and get a public key to check the signature so that a fake email can be bounced. At the same time it would enable end-to-end encryption.
And to forestall the usual reply - yes I do know PGP is available for my mail client. The problem with using it is that I don't know anybody who uses it because anybody I exchange emails with doesn't know anybody who uses it because....well, because there's absolutely nothing in SMTP which expects it to be used by default. And the lack of a PKI. The solution would be to have SMTP extended to use the mail servers to provide the PKI and, after an interim roll-out phase, expect its use by default.
A lot of this information is already available in the headers, (eg SMTPA, DKIM signatures) but email clients don't display it in any easily accessible way (which is your point about the headers), and they are not available for all email systems.
As these new RFCs are developed it would be good to see the IETF keeping an eye on usable indicators or flags that can be quickly displayed in email clients (rather like Gmail does now with indicating an encrypted SMTP channel or otherwise in their web client).
It's not enough to be secure, you've got to show people that you are secure so that they will learn to value it better.
Thunderbird plugin as a proof of concept?
There's SSL/TLS support baked into the protocol. PGP doesn't solve anything unless you don't trust SSL/TLS because you believe the NSA & friends have backdoors into it. But PGP never got much commercial support - expect most of the efforts directed towards SSL/TLS implementations.
How to trust the other party is the critical issue in both protocols.
Trust on First Use doesn't solve the problem, because legacy compatibility downgrade attacks mean the problem cannot be solved at the SMTP layer. It's time for people to stop trying to devise doomed work-arounds and instead move to increase adoption of S/MIME, which has the potential to help, but has benn hamstrung by inadequate PKI infrastructure. Imagine if Apple or Google provided automatic S/MIME carts using the same kind of automated provisioning Let's Encrypt has.
LOL! Google that helps you to avoid it reads your emails... Google may be interested in encrypting the transfer channel, as long as it can put its nose in your emails stored in its servers...
Besides that, there are other situations where for regulatory and accountability reasons email may not use S/MIME for end-to-end encryption, but still may need to be encrypted properly while transmitted, and destination ensured.
They already do basically the same thing for key distribution for iMessage. The problem is that this would only help Apple user to Apple user emails, which means less than 1% of all emails.
There isn't any easy way for Apple to support this for say Outlook 365 or GMail users, and while Microsoft and Google (ha! good luck getting them to help make GMail data mining proof!) could do this for their users, it really only helps for emails within their ecosystem as well. The percentage of Gmail to Gmail emails may be higher than Apple to Apple, but it is still tiny.
The only way it could feasibly work is to add something to the MX record that tells where to find certificates for users in that domain. I would expect Google to do everything they can to delay and roadblock any RFC that attempts to do so. The US and most other governments in all parts of the world as well. To be honest, I don't expect to see standard peer to peer email encryption ala PGP or S/MIME in my lifetime.
It would be nice if somehow they could authenticate the sender of the email. Perhaps they could use some certificate that you PAID for (traceability) and could be revoked to verify the sender. If you didn't get one of these, it might straight into the bin. I'm sure that IETF could come up with something. Maybe there would be two classes of "sender certificates", one for reasonable use, and another for "heavy" users (I am sure there are cases of this). If upon checking the certificate the agency (whoever it is) finds out that you went from "casual" to "heavy", it would warn the person verifying. It might even stop spam in its tracks (which is the idea).
Please IETF, come up with something to stop the flood of spam. Judging from my domain, it is about 90% of the email I actually get!
This is a 5-day-old "00" version of a personal draft. That makes it a long way from being an IETF draft and even longer from being possibly approved as a standards track RFC. It will be discussed at the IETF in a couple of weeks, so there may be some meaningful feedback after that.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
