My thoughts about Secure Mail Exchange (SMX)

Post date: Jan 4, 2014 2:40:27 PM

Studied Secure Mail Exchange (SMX) concept draft (20131219 revision).

TL;DR; SMX is normal encrypted email, with unencrypted connection options fully disabled.

Here's a few thoughts about it:

First of all, they're misusing terminology. 'SMX requires end-to-end (sender to recipient) authentication and transit encryption' - That's not true, it's not end-to-end encryption. If data is decrypted during transit at any stage, as it is. They should say instead that it's link encryption. Even if every link is required to be encrypted, it doesn't transform it to end-to-end encryption.
'S2SE Frequently, mail servers use self-signed or other untrusted certificates, which provides no meaningful authentication value' - Like I wrote in my earlier post, self-signed or untrusted certificates are only "no value", if those aren't utilized. Those can be used with fingerprint, and with that configuration, those provide much stronger identity than signed and trusted certificates, unless there has been done work to purge all unnecessary certificate authorities from trusted list. Even then, it's possible to generate new key and get new trusted signed certificate, which your server would trust, even if it's not the public key isn't same any more. This is basic problem with current system, and there's no fix for it and as we know, it's not very secure at all.
S2CE section - If authentication method is plain, as it often is. Same exploits can be used to attack clients with MitM, and steal authentication credentials / data. Using exactly specified fingerprint here would be much safer.
'EPs Encrypted payloads require that both sender and recipients agree upon an encryption method, and that they exchange encryption keys.' - Well, it's how they exchange keys. If I agree that the encrypted attachment is encrypted using my PGP key and we check our public key fingerprints over telephone, it's again much more secure than the options suggested here. As usual it's good idea to verify the public key fingerprint out of band.
'EPs provide end-to-end content protection, but do not guard against forgery.' - Now we can agree that there's end-to-end encryption. In case strong encryption key (PSK) or attachments are signed, it's highly likely that any forgery will fail.
OBSM - This is something we can agree about. Actually I got message just like that from F-Secure, I spent something like half an hour, checking IP addresses, message headers, signatures, urls and everything before I was sure it's ok to open it. Screenshot.
CMS - Well, for CMS providers it would be extremely easy to configure systems to require certificates & server authentication for major service providers. Like Yahoo, Gmail, Outook, Office 365 etc. But this would most probably cause problems due to historical reasons. It's totally normal that people send email all the time, without using the mail servers which are official mail servers for the domain. So they're basically forging their own emails. Before there were large authenticated SMTP service providers, it was common (and still is), to use the ISP's SMTP server for outgoing mail. This means that when I'm using mobile, mails are sent using my mobile operators SMTP server, when I'm at office, mail are sent by the office email service providers SMTP server. Yes, it might not be the same service provider which is actually handling receiving mail for our domain, etc. When I send work mail from home, it's sent using my home ISP's SMTP server etc. Yes, this isn't anymore as common as it was 10 years ago. But I see it still happening all the time.
SMX Requirements - Authentication mechanism not trivial. Well, I hope that excludes the plain authentication I was complaining about earlier. Anyway, all it takes is get the user to use once webmail, and all the benefit is lost, because browser doesn't support encrypted authentication. Of course it could be implemented using javascript encryption, which can be surely taken down trivially by the same attacker which is already doing the MitM attack.
Requirement to use SPF is nice, because it's simple and easy. But what's the point really? If the servers are authenticated by using strong PKI, basically its should be still much stronger than the SPF 'authentication'. One stronger alternative would be using DKIM, when it's in use, it already authenticates the sender server strongly. One benefit of using PKI is that if someone gets forged or parallel certificate for the domain / server, he still can't send email with it to recipients. Because SPF will drop those. But SPF is technically quite weak, it's just a few DNS records. So I'm sure that SPF isn't going to be major challenge for such a attacker. SPF is kind of toy in security aspect, but it still works with spammers.
Effects - Yes I agree about effects. But there's one question. Non-repudiable, say what? I didn't see any strong signatures anywhere, so no. I don't think messages are in technical sense non-repudiable. May be to normal users yes, but not to system administrators. To make flow really non-repudiable, the recipients email server should send signed confirmation that it has received message and return it back to the sender. Of course you can see from logs that they said OK. But there's no cryptographic proof, that they confirmed the message to be received.
Limitations - I do agree with that section, it's very important section. Because this also clearly tells about end-to-end encryption violation. Server can't store messages unencrypted, if it doesn't have unencrypted messages in first place.

There was lot of discussino about this in LinkedIn Information Security Group. I did post some comments there, but because it's closed group, I won't quote the messages or replies here.

Want more reading? Check this out: My earlier post about securing email.

Also check out CheckTLS service, which allows you to check if your email is configured securely already.