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

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)

Create a secure, trusted (in theory at least) framework then plug it into Microsoft Outbreak, er.. Outlook.

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

And what are they using instead? Carrier Pigeons?

Can't wait for the first commercial service. I'm there!

I think the "abandonment" comment might have been referring to webmail via SSL (with associated secure login) being preferred over POP3/SMTP in plain text. My ISP still doesn't offer TLS or SSL for POP3 logins and *anyone* can send SMTP as anyone else.

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.

and therein lies the rub - and perhaps the answer to Rich's question.

PKI is hierarchical - great for the military and those who work with them, it reinforces familiar (and comforting!) notions of 'superiority' and 'inferiority' - it specifically does not address the 'global village' appeal of insecure email.

A globally secure-enough email infrastructure based on PKI would require a huge single hierarchy (ultimately),a 'triangle of trust' if you will, based on certificates; no real performance penalty that anyone would notice, just an administrative nightmare. Oh! and the question of finding the ultimate head of the triangle in whom all trusters trust...

Mircosfot? doubt it!

*any* commercial organisation (why? on what basis?)

The UN?

Paris Hilton? (only reason for including avatar)

There are mechanisms for the distribution of trust that do not grow quite as quickly as a function of user numbers; there would still be the administrative issue around each user 'opting in' or not; the candidates of which I am aware (SPKI/SDSI) seem not to have been adopted in practise...

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

twaddle. Pray tell how an incompletely populated distinguished name directory 'solves' secure-enough email problem??

And anyway, as the authors of the RFC for SPKI discuss (x.509 is the specification ofr the certificates used in a PKI):

"X.500 was to be a global, distributed database of named entities: people, computers, printers, etc. In other words, it was to be a global, on-line telephone book. The organizations owning some portion of the name space would maintain that portion and possibly even provide the computers on which it was stored. X.509 certificates were defined to bind public keys to X.500 path names (Distinguished Names) with the intention of noting which keyholder had permission to modify which X.500 directory nodes. In fact, the X.509 data record was originally designed to hold a password instead of a public key as the record-access authentication mechanism. The original X.500 plan is unlikely ever to come to fruition. Collections of directory entries (such as employee lists, customer lists, contact lists, etc.) are considered valuable or even confidential by those owning the lists and are not likely to be released to the world in the form of an X.500 directory sub-tree. For an extreme example, imagine the CIA adding its directory of agents to a world-wide X.500 pool. The X.500 idea of a distinguished name (a single, globally unique name that everyone could use when referring to an entity) is also not likely to occur. That idea requires a single, global naming discipline and there are too many entities already in the business of defining names not under a single discipline. Legacy therefore militates against such an idea."

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

MeThinks the problem is that the military and governments are frightened to use e-mail and the Internet, because of the trail that it will always leave. Not good whenever you are spreading terrorism around the globe to support all those weapons sales to combat the terrorism you're pushing.

What on earth does Saudi Arabia want with $20 billion worth of new missiles. Strewth George, O Uncle Sam, a blind man on a galloping horse can see through that pathetic scam. The sub-prime contagion is rotting your brain.

And boy are they gonna squirm whenever "sensitive" e-mails which are not theirs and which they would choose to ignore because of their sensitivity are shared for the world and his dog to see on the Internet. And don't embarrass yourself by jumping to a false blackmail conclusion whenever it would be much more danegeld, because you can be sure that some would think that Novel Thoughts Shared Transparently in Future Systems of Power and Control have no place in Present Systems, which they are free to Abuse under the Comfort Blanket of State Secrets and National Security and how dumb would that be?

The Transparency they waffle on about is and is proving to be a clear as Mud. But hey, it is very convenient to hide Ignorance and the Scams and Get Rich Quick Schemes of Government and Business behind.

And don't spin me that yarn, the cheque is in the post, for if it aint cashed it aint paid.

Ok Rant over. Gordon promised Change and he would like to be remembered as being true to his Word even if he elects to do IT by Proxy.....although that is plausibly deniable.

Excellent!

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

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

'Web of trust' infrastructures do already exist. Thawte have one for personal email certificates.

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

For DKIM there is, but you'll probably have to use it where MTAs establish client server connections with each other as opposed to on MUAs :

http://sourceforge.net/projects/dkim-milter/

Just a thought...

is sort-of along the idea that SPKI/SDSI was (is?) investigating as a flatter-than-PKI-hierarchy for dissemination of trust

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