Automatic e-mail encryption

[Ingo Klöcker]

Hi Peter,

please do not send me direct replies. I am subscribed so reply-to-list 
is sufficient. (I wouldn't ask this of you if I'd receive two copies of 
your replies, but I only receive the direct replies and this means I 
cannot use reply-to-list. The mailing list is correctly configured, so I 
blame a fancy deduplication feature of the receiving Exchange mail 
server.)


On Saturday 19 July 2014 14:26:44 Peter Lebbing wrote:
> Here's an idea: when elliptic curve becomes ubiquitous, simply include
> your public key in the header of every e-mail you send. That's way
> closer to how SSH works, since it uses only one channel, in this case
> the e-mails themselves. Perhaps it would be a good idea to only
> include the actual EC public key, and not the whole OpenPGP packet,
> to keep it small.

I like this idea.


> You say signing isn't covered... I don't see why not. Just as you
> automatically decrypt; automatically sign.

It doesn't feel right to automatically sign messages with automatically 
created keys. Also, signing is irrelevant for my use case: end-to-end 
encryption.


> There still is the large issue of private key distribution. I have
> several machines all connected to my e-mail account. It seems to me
> there's a *lot* of infrastructure still missing for this to be almost
> transparent to the end-user.

Yeah. Usage of multiple machines/devices is an unsolved problem.


> This topic, if discussed at all, should
> be discussed by itself and not as some kind of counter-offer to
> symmetric encryption, because the problem space is vastly different.

Right. I guess I simply grabbed the opportunity.


> By the way: if we had a working alternative to SSL/TLS, all the mail
> servers could talk to eachother securely without eavesdropping. That
> way the contents of e-mails is only exposed on the sending SMTP
> server and the receiving SMTP and mailbox servers (f.e., IMAP). The
> mailbox server already knows when you use automatic decryption to
> facilitate searching,

unless the decrypted messages are only stored locally. Yes, this would 
break server-side searching and is problematic on devices with limited 
storage capacity.


> and the receiving SMTP server is probably under
> the control of the same people that control the receiving mailbox
> server. So they are probably about equally difficult to access. And
> likewise, the sender will have a decrypted copy in his Sent folder on
> his mailbox server,

unless ...


> and the sending SMTP server is again close to
> that server. So if only we had a way to properly authenticate SMTP
> servers, I think we get almost the same effective protection for the
> users, albeit without signatures. And this requires only changes to a
> "couple of" servers, instead of to all endpoints.

Good news: I think we do have such a way. It's called DANE (DNS-based 
Authentication of Named Entities) [1].

Support for DANE has been added to Postfix a few months ago and a few 
German mail providers recently started using it.


Regards,
Ingo


[1] https://tools.ietf.org/html/rfc6698
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20140719/7661c938/attachment.sig>