[Mailman-Developers] GSoC Project: pgp plugin

[Stephen J. Turnbull]

Jonas writes:

 > The Project Idea:
 > Encrypted malinglists have been been a much-requested feature in mailman
 > 2 and I would like to run some encrypted mailinglists myself.

I see Abhilash has already mentioned that he has done some work on
crypto (PGP) in Mailman 3.  I'll let him explain that.

I agree that this capability is very desirable for some use cases, so
I too welcome your application.

 > There is no stable pgp-aware mailserver

Please be careful about terminology.  In software, the suffix "-aware"
is pretty weak.  It could mean as little as "oh, this MIME body has a
signature, so we should not touch the MIME body" (eg, to add the usual
footer).  I'm not sure what would be appropriate terminology here (the
problem is that requirements are completely undefined, but in security
applications requirements must be precisely specified -- if somebody
uses your application inappropriately because you built something other
than what they need, "I'm sorry" doesn't begin to cover the damage).
"PGP-enabled" will do for now.

 > Some features could be:
 >  1. Automatic pubkey collection from inbound mail

Collect, maybe, but enable, no.  Mail as such cannot be trusted.  You
would basically need to do a triple handshake with the address to
confirm that that address indeed has access to that key and the key's
owner has the right to use that address.

 >  2. Outbound mail encryption and signature validation
 >  4. Inbound mail decryption and outbound mail signature

I don't understand these pairs.  Why encrypt mail *to* the server if
it's only going to be decrypted on the way out?  Why encrypt outgoing
posts if they might have been read in the clear before being received?
End-to-end encryption or signature or both seems to be the right thing.

 >  3. Automatic keypair generation for pgp-aware lists

Out of scope for one summer IMHO.  It's not obvious what the security
implications are.  Better to do key generation off-line.

 >  5. A mailinterface for organizing the encrypted lists, subscribers
 >     public keys and trust levels
 >  6. A webinterface

These too are out of scope.  Again, security implications are unclear.

 >  7. PGP Information in the messages (e.g. was the incoming mail signed
 >     by a trusted subscriber?)

What does "trusted" mean?

 >  8. Optionally forced encryption (such a list never sends mail to an
 >     adress to which it can't encrypt with a pubkey that has a certain
 >     level of trust and/or won't accept inbound mail in plaintext)
 >  9. Optionally forced signature (inbound mail to the list has to be
 >     signed with a key that has a certain level of trust in order to be
 >     published)

I don't understand how you propose to manage "trust levels".  And
"optional", if you want it optional, why are you bothering in the
first place?  That just makes the whole list unreliable as far as
security goes, because you never know what's going to happen.

 > 10. pgp-aware command system. (eg optionally only accept admin mail
 >     commands from signature-verified mail admins)

I don't understand this.  Mailman doesn't actually have that many
admin mail commands, and the signature requirement is easily bypassed
by doing the same operations from the web.

 > What are your thoughts on pgp in Mailman 3?

My thought is "what is your threat model"?

 > Is this a suitable Project for the Google Summer of Code 2016?

Yes, crypto support (both encryption and signatures) are a FAQ.
However, nobody has ever really provided specific requirements (ie,
the threat model to defend against), so it's very hard to decide what
to do, and documentation of whatever is done would be impossible.

 > Would anyone be interested in becoming my mentor for this project?

Subject to acceptance, I can be a co-mentor (I was Abhilash's mentor)
but probably cannot be primary (I have another proposed project where
I'm the obvious primary since I'm the only one who currently has the
relevant knowledge).

As far as acceptance goes, please see
http://wiki.list.org/DEV/Google_Summer_of_Code_2016 for information
about our requirements and procedures for student applications.

Regards,
Steve