[Mailman-Developers] GSoC Project: pgp plugin

Fri Mar 18 18:17:13 EDT 2016

Hi Jonas,

On 03/18/2016 10:29 AM, Jonas wrote:
> 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.

Great!

> 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?

I guess you can upload drafts of proposal (in google docs) on GSoC's
website and we all mentors can have a look at it/comment on it if needed.

> 
> 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.

We need you to fix one easy bug so as to judge your capability to
actually implement the proposal that you are proposing. Although, we
have mandated one patch towards your application, a small documentation
patch and some of your previous patches to different projects
(preferably, but not required, in Python) could work. Does that sound
good? I can point you to several places we need more documentation ;-)

> 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
>>
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> https://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40gmail.com
> 
> Security Policy: http://wiki.list.org/x/QIA9
> 

-- 
thanks,
Abhilash Raj