[Mailman-Developers] GSoC Project: pgp plugin

[Jonas]

Thank you Stephen.

I agree with your points and I will make sure to clearly document any
potential security pitfalls of the system for the users and to write a
detailed and precise design plan that has special emphasis on security
implications before I start coding this project.

However, at the moment I'm in the middle of writing my Project Proposal.
May I send you a draft along with personal questions?
And/Or Abhilash Raj, may I send you those?

To make a first impression, I thought about writing a general blog post
on the state of mailinglist/group communication encryption that covers
the efforts toward encrypted lists in mailman. Could that work as a
first impression instead of fixing a bug in mailman? The easier ones
seem to get patched faster than I can catch up.

Thank you again,
Jonas

On 29.02.2016 21:49, Stephen J. Turnbull wrote:
> 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
>