5 ms·
Just why isn't key distribution an SMTP extention? I'd expect there to be an RFC for it, but I couldn't find anything. (I'm not talking about DomainKeys. I'm as
by pjungwir 13y ago
Just why isn't key distribution an SMTP extention? I'd expect there to be an RFC for it, but I couldn't find anything. (I'm not talking about DomainKeys. I'm asking why an SMTP client can't ask for a recipient's public key, and if it exists do the encryption.) Here is a blog post about it:
http://www.illuminatedcomputing.com/posts/2013/07/public-keys-via-smtp/ http://www.illuminatedcomputing.com/posts/2013/07/public-key...
- specialist 13y agoI've always assumed that encrypting my communications is akin to demanding the authorities pay special attention to my activities.
- cabalamat 13y agoThat's why everyone should do it. For everything.
- pjungwir 13y agoI think defaulting to encryption is great for businesses. A friend who does security policy for a big corporation is always complaining about data egress, and closing even one vector would help. And within the corp you control the MTA and MUAs, so you could at least secure intra-corp communications. To him, leaking info to a competitor or the public is a bigger deal than the NSA.
- specialist 13y agoAbsolutely. I implemented 5 regional health information exchanges. We resigned ourselves to accepting that a disclosure was a matter of when, not if.
- cabalamat 13y agoI'm currently writing software that essentially does this. It doesn't put the key in the SMTP protocol, but in the mail header, e.g. X-Purrcat-Key: ...public key goes here....
- steveklabnik 13y agoPlease note that the X- pattern is considered deprecated: http://tools.ietf.org/html/rfc6648 http://tools.ietf.org/html/rfc6648 TL;DR: just make your header Purrcat-Key.
- cabalamat 13y agoThanks for the info.
- pjungwir 13y agoWell I commend you for moving things forward! Have you talked with any security professionals about possible pitfalls of using mail headers? I was sort of hoping tptacek would come on and tell me why my idea is no good. :-)
- cabalamat 13y agoNot yet, though the project will be open sourced, which will hopefully enable other people to catch any security holes I've left in it.
- RexM 13y agoThis seems like it would work if you wanted to encrypt a reply message, however how would you get another user's public key if you're the one initiating the first conversation?
- cdjk 13y agoThere is TLS for SMTP, which admittedly doesn't protect the email once it gets to the server, but at least helps en-route. Also, I don't think there's a problem around the fact that most of the time you don't communicate directly with the recipient's smtp server - relaying is definitely a part of SMTP. It would work in the case of running your own SMTP server that you use to relay mail (assuming you encrypt your own SMTP sessions), but you'd need smtp servers to recursively query for the public key if you want to enable relaying. This is starting to sound suspiciously like DNS, so why not just store the keys there? There are already ways to do that: http://www.gushi.org/make-dns-cert/HOWTO.html http://www.gushi.org/make-dns-cert/HOWTO.html Add in DNSSEC records and you can be pretty certain you have the right key.
- pjungwir 13y agoThank you for replying! Relaying does seem like a fatal flaw. DNS seemed like a bad match for per-user information (rather than per-domain), but indeed that HOWTO gives a nice way of working around that. So it's just a question of MUA PGP modules trying that mechanism.