Is trying to fix (E)SMTP really worth it? [part 2 - infrastructure]
[digg=http://digg.com/security/Is_trying_to_fix_E_SMTP_really_worth_it_part_2]This article is the second in my series about the flaws of (E)SMTP, the whole Internet mail infrastructure and how it could possibly be fixed. The main focus of this part is a new approach to the infrastructure which should help making emailing more secure, reliable and less spam-prone.
The first article can be found here and points out flaws and problems in the current systems.
Before going into detail about how the infrastructure could look like I would like to point out the goals of my proposal:
- security through end-to-end encryption
- security through sender and server authentication
- integrity of message contents
- built-in load-balancing support
- getting rid of email forwards
These five major points should be covered directly by a new infrastructure and should be mandatory. There is no point in making any of these optional as the rest of this article should point out.
security through end-to-end encryption
Even though both SSL and TLS support exist for (E)SMTP these features are optional. In fact this means that it is possible that even though one submits his or her email over a secure channel the message could be transferred in plain-text somewhere on the way to its destination.
This enables an attacker to snoop at your message somewhere along its way. Whilst some people believe this is okay I strongly oppose to anyone being able to read either my private or business emails.
The solution to this problem is end-to-end encryption. The new infrastructure should make encryption of all message exchanged mandatory and further provide a way of encrypting the message contents. This way only the intended recipient can actually read the message (as in not even a server administrator having direct access to a user's mailbox). End-to-end encryption of the communication channels should be done by using TLS for all communication between all clients and servers and for server-to-server communication.
Encrypting of the message payload could be done in a similar (if not even the same) way OpenPGP (RFC 4880) works.
security through sender and server authentication
The next feature a possible SMTP successor should provide is sender and server authentication. As TLS should be mandatory for the implementation the easiest way to achieve this is using a public key infrastructure. This could then in turn be used for multiple things, including message integrity checking, encryption of message contents, authentication of the sender and authentication of the server.
Integrating a public key infrastructure could be done by having special DNS (maybe TXT) records that contain the address of key servers. These key servers would store not only a domain-root certificate which would allow user and server authentication but also all user and server certificates themselves.
A receiving server could then check the sending domain's key server for both the domain-root certificate and the sending server and thus verify that the message is legitimate and actually originated from the specified domain.
Sender authentication works together with message integrity. Basically the receiving server opens the message, gets the client's message signature from the message, and asks the sending domain's key server for the public key of the sender. The receiving server then checks the signature and this way verifies the sender.
integrity of message contents
Integrity checking is closely related to sender verification. As the receiving server checks the sender's message signature in the sender-verification process the message is automatically checked for integrity too.
built-in load-balancing support
Load-balancing is also closely related to the PKI approach. The sending server could use the receiving domain's key server to locate the server to send the message to. This way load-balancing of receiving servers can easily be implemented. Furthermore load-balancing of multiple key servers for a single domain is possible using DNS round-robin records.
getting rid of email forwards
Forwards can also be gotten rid of by using the receiving domain's key server similarily to the load-balancing approach. Instead of pointing the sender to a domain-local receiving server the key server could simply point the sender to another domain's receiving server. This way the message would not really be forwarded or relayed anymore but rather a pointer to where the message should be stored could be provided.
Putting everything together
Making all the mentioned features mandatory for a possible successor of SMTP should make users benefit in a few ways. Firstly, users could rely on both then integrity of the message, that the sender actually the person he or she pretends to be and the fact that snooping on the contents of the messages they send is hard to impossible.
Furthermore this infrastructure should make sending SPAM messages a lot harder as domains for sending spam would have to be bought, DNS servers and key servers would need to be operated and blocking unwanted messages could be as easy as blocking either a domain or a single user using the information provided through their message signature.
ISPs would benefit from the built-in load-balancing mechanisms and the mailbox alias feature (forwarder). Whilst the load-balancing technique simplifies set-up and operating of a load-balanced infrastructure the mailbox alias feature should help cutting down on traffic generated by email forwarders.
Please be aware that I intentionally left out all implementation specific details, such as the message exchange protocols. More technical aspects of a possible implementation are to be covered in the next parts of this series. As always, comments are highly appreciated.