I'm quite surprised that considering the very long-standing problems with email security and authentication, nobody has submitted a "method of transmitting email in a secure way" RFC.

I'm sure there are enough ideas out there to make this happen, but nobody seems to have picked up the baton. You could argue that the main reason is the issue of compatibility with the existing SMTP protocol. I don't think this would be a major problem though. If we had a good secure standard that had merit and widespread support then I would expect net users would move over to it pretty quickly; I know I would. OK, you'd probably have to run parallel mail servers for a while but so what? It would only be temporary.

You could say "well, why don't YOU come up with something then". My answer to that would be that I don't know enough about the subtle issues involved, and besides, nobody would listen to me :-)

There ARE enough knowledgeable and influential people and organisations out there that could do it though. No idea why nobody has even tried (well, until now, it seems, but then there seems to be a question over whether the spec will be widely distributed, so this attempt could be a no-go for general use).

...X400/X500 in a pretty dress (albeit a camouflaged one)

""People"? What "People"? Who's abandoning it?"

And what are they using instead? Carrier Pigeons?

There have been a number of "surveys" reported over the last few years that apparently "show" that "some people" are gradually ditching email in favour of text messaging, IM, messaging in social apps like MySpace/Facebook, carrier pigeon, cans and string, etc. Primarily due to spam, they say.

Idiots, I say. Learn how to use anti-spam properly or get a better email account. My Gmail account; 3253 pieces of spam caught in the last month, about 2 got through to my inbox.

...as Steve pointed out, X.400 and X.500 solved this problem twenty years ago.

Admittedly twenty years ago, times were different. A typical computer had no Internet connection, maybe 64kB of memory, maybe 1MB on a big one. Remote sites might interconnect at 9600 baud. X.400 and X.500 had security designed in from the ground up, which made them a bit oversized and slow for many of the computers and networks of the 1980s, whereas POP and SMTP could be used by anything marginally more intelligent than a Teletype(R), so X.400 and X.500 ended up being used only where security and the like really really mattered.

Move the clock forward 20 years, 95%+ of email is junk, most of it is spam, and stuff that matters can't be trusted to be from the person it says it's from, and there's no way of knowing whether it's been tampered with in the post.

Meanwhile practically every PC in the world has more than enough memory and processing power and network bandwidth to run a sensible email system which is smart enough to know that if an email from the Bank Of Scotland doesn't have the relevant attributes, it probably isn't from the Bank of Scotland.

Bye bye Outlook, and not before time?

Bye bye connectivity-focused ISPs, whose vision of an "email service" is Squirrelmail and an SMTP and POP server farm, without caring a jot about identity services and security?

If google and yahoo don't *know* (or can't prove) who their users are, why should you trust an email from a gmail or yahoo address?

You know it makes sense, and not just for the military + commercial markets.

for the hack of the central key database purloining millions of keys. After all, they're supposed to be public keys, aren't they ?

And when all those public keys have been purloined and we find out that they are but 64-bit RCS keys (that take about a day to crack nowadays), what then ?

After all, the military doesn't really have a stellar record in web security on sites that are not supposed to be open to the public, and unless the central key storage is on some platform that is inherently secure (nothing Microsoft then), it'll be a prime target for spammers all over the world.

"Where's the RFCs?" . You might want to have a look at the RFC for DKIM RFC4871 for starters. DKIM will enable you to know which domain sent an email. Making this an anti-spam solution will also require a domain reputation system so we know which domains spam comes from and the willingness to penalise (e.g. by adding a couple of spamassassin points to) and eventually reject all non-DKIM signed mail.

DNSSEC will go a lot further but will probably take longer to come out of research into the field. Having a secure DNS will make it possible to associate knowledge of a DNS or email address with signing and cryptography keys and certificates signed for and by the associated domain.

OK, here's an idea then. I've just made this up and I don't doubt there are flaws in my logic, but if I can think of something that might even half work, then I'm sure if we put our heads together, we can come up with something that fully works. It's not rocket science!

And for the record, all the following avoids needing to use a huge centralised database / certificate /identity repository.

Secure Transit

--------------

This is simple to address. We all have private/public keys. If someone wants to send me an email, their email server asks my email server for my public key. Using that, the sender (1) determines whether who they are talking to really is who they think they are talking to and (2) encrypts his/her email to me (using my public cert) and sends it on its merry way to me. While they're at it, they could sign their email with their private key so that when I receive it, I can verify that it did indeed come from the person I think it did.

This is simple, very well understood, and could even be supported by extending the current SMTP protocol, and indeed SMTP already supports encrypted transfer via TLS. To extend this to individual email accounts we could do something like...

HELO

THIS_IS_ME sender@example.com <senders public cert>

(reply from my email server is "ok" or "bugger off")

CERT_REQUEST rich@example.com

(reply from my email server would be "bugger off" or <rich's public cert>)

Authentication

--------------

That's already addressed (above) - the sender passes their public cert to my email server and from this, my email server decides whether or not to allow the email to be sent

New Senders

-----------

This is a trickier problem. How does the sender send me an email if I don't already know them (and therefore don't already have a copy of their public cert, and therefore can't say for sure whether I want to receive email from them or not)? And how do we do this WITHOUT having to rely on some "tree of trust" or some such?

One answer (or one collection of answers) could be...

I could apply some rules to my server so that when it receives a "THIS_IS_ME" command over the SMTP, and I don't already know the sender, I could reject the email outright, allow it in but flag it internally to say it is untrusted, etc etc. This wouldn't stop SPAM though without also (probably) stopping legitimate email. I could maybe improve the situation my adding more complex rules. One option may be to extend the "THIS_IS_ME" command to something like :-

THIS_IS_ME sender@example.com <senders public cert>

I'M_A_MATE_OF <someone I already know> and here's a signed recommendation from them <sender's info signed by "someone I already know">

If my email server is happy with the recommendation then it'll allow the email in

If the sender doesn't know any of my mates and so can't get a recommendation from them then we have a further problem. One crude answer (if the rules-based filtering method doesn't wash with you) could be :-

THIS_IS_ME sender@example.com <senders public cert> <sender's "small intro message" asking to speak to me>

(reply from my email server is "bugger off" or "I don't know you, but I'll read your "small intro message" and let you know if I will accept your email. Try again in a couple of hours if you don't hear back from me)

Of course the "small intro message" would be just that - simple text, and only just long enough to say hello. Not big enough to send a virus or a jpeg of a naked Latvian turnip farmer, etc.

I'll shut up now.

Excellent!

Errr... I'm guessing there's no actual email client/server support yet?

Not as useful as it could be.... :-(

...Basically. Hell, maybe they will wrap it in a x400/x500 style protocol as well, and just make it unusable.

As for the tosser who reckoned that the x?00s would get rid of Outlook, Exchange actually speaks x400 natively. SMTP is the johnny-come-lately in Exchange server world. And despite its vaunted idiot-proofing, x400 is still a bitch to get set up correctly, even there.

SMTP has simple + interoperable. x400 had sender verification to the MTA (so does SMTP AUTH), but not end-to-end *security*. I think there needs to be a complete rejigging of how message traffic is managed - discrete mail packets traversing the intarwebs on a store-and-forward basis seems so retro - to achieve the simple + interoperable + secure magic grail. Getting everyone to agree on just what standards are required to put that in place is another challenge.

SPF/DKIM is a good addition in the SMTP space, but it's just another bolt-on to a fundamentally insecure system. Still, it's nice you can generate your own certs for DKIM and not pay through the nose to Verisign et al to have full end-to-end encryption. If certs were a reasonable price, many more organisations would use TLS for email. Again, another bolt-on to SMTP, but better than nothing.

Look at the documentation on www.Echoworx.com site. They have built a PKI distributed system e-mail system using the big Telco company across the world.

PS: No, I am not from or have interest or use their system...

Shees if identity is all that important that's not hard to do... take the current SMTP protocol,

make a PGP authority that will assign keys to the users of said server. Have all mail be atleast signed

if not encrypted. Then before processing the mail further figure out if said user is who he claims to be.

If not drop the mail. If yes start processing it...

There... I'd like my 0.02 euro cents now please :)

PGP/GPG?

Can anyone tell me what all this PKI nonsense does that it doesn't? Digital Signatures, check. Encryption, check. You just have to add a public key fingerprint to your business card next to the email address and you're all done. And it works fine over the existing infrastructure.

Here's a thought:

When a domain is registered, a public key must be associated with that domain.

When mail is sent out, a signature is created by the mailing system of the sender WHICH MUST INCLUDE the sender's e-mail address and the date/time of the e-mail.

On the receiving end, the mail server receives the mail, queries its DNS for the public key and checks the mail is what it purports to be and by the person who supposedly sent it.

Advantages: It does not require individual users to create their own key (they still can, for security purposes, but they don't *have* to in order to be authenticated). Also, it allows spam e-mail to be traced back to their source of origin (assuming the signature algorithm has been written properly).

Disadvantage: You are still susceptible to xDNS attacks, where the DNS information you require (including public key) has been compromised or replaced by a new set.

The solution you propose, involving the "bob" server giving "alice" his public key, is vulnerable to man in the middle attacks (as are all variants of it).

That's why SSL needs the server owner to obtain a certificate from a CA (at a cost of $$$) to protect against this. Which is basically back to the PKI problem - to use crypto email, you need to be vouched by a central authority.