[Mailman-Developers] GSoC Project: pgp plugin

[Stephen J. Turnbull]

Jonas writes:

 > On 28.02.2016 10:30, Stephen J. Turnbull wrote:

 > > End-to-end encryption or signature or both seems to be the right
 > > thing.
 > 
 > The concept of a mailserver doesn't allow real end-to-end encryption if
 > each recipient uses a different keypair.

It's true that keeping things secret from the server would be hard,
but at least in theory it would be possible to avoid decryption in
normal operation by having the originator use a "session key" and a
symmetric algorithm to do the actual encryption, and then using the
user's PGP key to encrypt the session key.  Then all you need to do is
decrypt the session key and reencrypt it with the user's (or users')
key(s).

If possible (I mean I suspect it requires privacy software that
doesn't currently exist) this would be nice because you don't have to
worry about having copies of decrypted text in memory, in swap, and in
temporary files.[1]  Of course this would mean that such an MLM could
not decorate the mail with header or footer, but you probably should
not do that anyway because of limitations of MUAs and users in
displaying/interpreting indications of what portions of a message are
secure.

 > Considering that all subscribers recieve the mail and usually
 > listserver admins are subscribers theirselves,

In security, you either need to take care of the unusual case, or
document that the case is not covered.  Wouldn't you rather have a
short list of "you can't use my software in these cases: ..."?

 > I think than an implementation where the listserver recieves a copy
 > as well definitly has some uses.

Copy of the encrypted message, maybe, although I would argue that
archiving should default to off for an encrypted list.  But decrypted,
I disagree strongly, and would do my best to block integration of such
a feature (it's Barry's call in the end, not mine).  If you really
want the server to have a decrypted copy, that is easily enough
accomplished by subscribing a decryption program to the list.  Our
goal should be to do our best to reduce the additional attack surface
presented by the MLM by default, and leave the users to their own
devices in reducing security and increasing risk.

 > Users would have to be aware that the privacy of communication
 > relies on the protection of the listserver and listserver admins
 > would have to be aware that they need to protect the lists keypair.

If there's anything we know about users, it's that they only learn
about security when they experience harm from lack of it, and even
then few actually do anything effective about it.[2]  Admins have
enough to worry about without drawing an arrow labeled "attack here"
on their system (running an encrypted list already paints a bullseye
on it).  Whenever possible, we want random clueless behavior to *not*
result in a security hole.  So yes, the private keys must be
protected.  But as much as possible we should try to ensure that if
the list server is compromised, the communications are not.

 >> [Automated key generation is out] of scope for one summer IMHO.
 >> It's not obvious what the security implications are.  Better to do
 >> key generation off-line.

 > What security implications are you refering to? Some servers have
 > true hardware rngs. If there isn't enough entropy, no keys should
 > generate with /dev/random as entropy source.  Having the proper
 > crypto libraries and random number sources is in the responsibility
 > of the user.

I'm not talking about the availability of these basic facilities.  If
the system doesn't have them, none of the necessary crypto facilities
will be available from Python anyway.  I'm talking about the
introduction of unnecessary complexity.  I don't know offhand how to
attack it.  I'm saying that before we introduce additional complexity
we need to be pretty sure that it's hard to attack.

If you want to do this, you need to learn the security mindset[3].
Otherwise, you're very likely going to leave behind bugs that someday
will bite somebody who is earnestly trying to do the right thing.

Back in the day, I set the config on Smail 3.1.0.99 to block outside-
to-outside relays, as recommended by the documentation.  I was shocked
to be informed a few weeks later that my box was being used as an open
relay.  Guess what?  They documented that feature, but the
implementation was a stub until 3.1.0.101.

 > With this concept, there will be a private key on the listserver and
 > this should be clear to the users. It has security implications but I
 > think they are admissible.

Of course there has to be a private key usable by the list server
because the whole purpose of the exercise is to avoid distribution of
all keys to all subscribers.  But stealing the keys is only one of the
many ways to get past a lock.  We need to protect the hinges on the
other side of the door, too.  The most effective way to do that is to
ensure they're not exposed in the first place.

 > > What does "trusted" mean?

 > Trusted means that the key has been marked as trusted by an authority
 > (list admin).

OK.

 > I'm not exactly sure what a threat model is.

Find out!  It's more than just a few random scenarios, I'll tell you
that much.

 > But a scenario this would protect from is eavesdropping on list
 > communication by a mailserver

How about one run by a subscriber?

 > – or anyone in case inter-mailserver communication or access to a
 > mailbox isn't properly secured.

You can assume that SMTP is unlikely to be secured.  TLS is more
common nowadays but hardly universal.

What makes you think that users won't save decrypted messages?  You
need to document that as a threat and exclude it from those you can
protect against.

 > I don't understand, why would documentation be impossible?

Users have a habit of assuming that "secure" (or whatever favorable
adjective is involved) applies to their use case.  You need to be able
to describe the threats that are and are not defended against in
detail and very clearly.

For example, one use case that has been brought up in the past is a
mailing list that contains private conversations among a group of
patients and the group therapist.  But you can expect that in the case
of a multi-therapist clinic, they will want to share a single server
with a professional administrator.  That server's admin presumably has
access to the list keys, but you don't want that in this use case, not
even if she is one of the therapists.

Thus, you need to make it clear that this scenario (a server admin who
should not have access to the privileged conversations) is *not*
included in *your* threat model.  Server admins are necessarily
trusted, and excluded as sources of security breaches.  If you don't
clearly specify that threat model in your design, you're not going to
be able to document it well enough for users to understand.


Footnotes: 
[1]  Think "the disk was stolen".  Private keys on that disk?  Not
necessarily.  What?  That wasn't part of your threat model?  Better
say so!

[2]  Consider how many people continue to use Windows!

[3]  https://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html