Wednesday, August 27, 2003

SMTP Wish List

While thinking about the various proposals for reducing/eliminating domain spoofing on e-mail (or at least, giving the destination servers the power to determine whether the domain is spoofed or not) - I also wondered why public key encryption has not also been added to SMTP yet so that inter-server communications is encrypted.

The public keys could be stored in DNS records or perhaps the origin SMTP server could merely ask the destination SMTP server for it's public key (ask for the hash first so that keys could be cached, only grab the full key if it's changed).

Lots of attacks possible as well as some implementation issues that I can think of right off the bat. Such as man-in-the-middle attacks that are possible if the SMTP servers get the keys directly from each other (DNS is a better source, especially if DNSSEC comes to pass so that DNS request packets can't be forged/faked). Also, do all of the domain's SMTP servers use a shared public key, or will it vary based on which MX record you use? I'm sure the various governments would also get involved and politics would come into play.

One possible avenue of implementation would be if say, Postfix were to implement a public-key exchange and use encryption when talking to other Postfix servers. Assuming the technical details aren't horrendous, it might then perculate into QMail and the other MTA software for inter-operability and marketing clout.

There's been at least one proposal floating around out there that tries to make IPSEC opportunistic by storing the public keys in DNS records - but that would require O/S vendors to get involved and I don't see Microsoft doing that any time soon. I think getting the SMTP traffic to implement opportunistic encryption is more likely because there's no monopoly in SMTP MTA software and it could easily become a selling point.

(This isn't even a new idea, I've found papers on the net going back to late-1990s proposing the same idea.)

posted by Wuphon's at 3:39 PM