Re: [Endymail] Off we go...

[Michael Kjörling <[e-mail]>]

On 27 Aug 2014 15:58 +0000, from [e-mail] (Viktor Dukhovni):
> So I'd like to see support for delivery-time encryption in LMTP
> servers (dovecot, ...).  This gets the recipient's mail protected
> in storage regardless of the payload encryption capabilities of
> the sender.  Yes, this is not an end-to-end mechanism, and it may
> be too late if at some point en-route the message was transmitted
> in the clear.

> What's the sweet-spot for protection of messages at rest that does
> not unacceptably impact usability?  Unlike IM conversations, that
> users expect to be largely ephemeral, people tend to "hoard" email
> as a long-term record of communication.

On the reverse side of the generally small, stamped, disk-shaped
metallic object to which we ascribe monetary value, otherwise known as
a coin, these to me both sound like implementation concerns.

There would be little stopping me from, today, taking an appropriate
library and adding it to the LMTP delivery chain code of my favorite
software. I could even almost certainly do something like the first
basically by chaining together procmail and gnupg/openssl/whatever on
the LMTP server and end user client side. Presto, email security at
rest server-side. No IETF work needed. With a few relatively simple
modifications, it should be possible to make the software guarantee
that (as far as the OS can guarantee it) a message never leaves server
RAM unencrypted. (We already have POP3 and IMAP4 over both SSL and
STARTTLS; it should be a relatively trivial change allowing encrypted
at rest messages to not be downloaded over an insecure connection.)

UAs can cache decryption keys for whatever period of time is deemed
reasonable, and the length of that period of time (and the allowed use
of cached keys without reauthentication) can be made configurable by
the user likely without overwhelming even relatively new users.
("Allow searching secure email without requiring a password" and
"Allow displaying secure email without requiring a password" could be
a start.) It wouldn't be perfect; for example, someone with a debugger
running on the system in question would be able to gain access to the
decryption keys; but then again at that point it's quite possible that
the user's system is rooted anyway, in which case transport security
doesn't help. (That needs quite different steps to mitigate, which
would seem to me to be outside of the scope of this discussion list.)

An issue that any end-to-end message encryption scheme would more or
less have to address, though, as I see it, is _how do I know that I am
encrypting to the right individual?_ Yes, computers could take care of
that part, especially once communications is established, but somehow
Alice still needs to know that she is sending that first message (and
encrypting it to) Bob Bravo, who uses [e-mail] because Mallory
snatched [e-mail]. Considering that e-mail address mistypes are
quite common in the wild, and may very well result in the message
actually being delivered to the wrong person, initial establishment of
secure communications seems like something that would need addressing
(figuratively _and_ literally).

-- 
Michael Kjörling • https://michael.kjorling.se • [e-mail]
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)