[Mailman-Developers] GSoC Project: pgp plugin

Mon Feb 29 06:32:18 EST 2016

On 02/29/2016 03:02 AM, Jonas wrote:
> Hi Abhilash Raj, Hi Steve
> 
> Thank you both for taking the time and considering to mentor me.
> 
> On 28.02.2016 04:48, Abhilash Raj wrote:
>> If you don't know, I worked on this project some time back in GSoC 2013.
>> The  current state of that project is not very good and probably needs a
>> *lot* of rebasing to do.
> 
> I did not know that. What were the problems?

I did implement the signature verification for the
application/pgp-signed emails and was able to get everything working
too. There was some plumbing left that I never went back to finish.

> 
> On 28.02.2016 04:48, Abhilash Raj wrote:
>> Here is a link[1] to discussions that have already been done before on this
> 
> I think that link is missing, I'm very interested in looking into this.

Sorry about that, here it is
http://www.mail-archive.com/mailman-developers%40python.org/msg13413.html.

> 
> First of all, if this wasn't clear, my plan was to make a re-encryption
> gateway. Messages are encrypted to the listservers keypair and
> re-encrypted there for each of the recipients.
> How did your implementation work, Abhilash Raj?

Kinda similar, just that I mostly focused on just implementing the key
management and verifying digital signatures and figuring out a message
structure that would let us retain signatures from both list and
original sender.

> 
> I had two modes of Operation in mind:
>  (a) One that doesn't encrypt all of the mail but gives users the option
> to send and recieve pgp encrypted mails. This might be useful for very
> small private lists where some communication is protected against
> eavesdropping in other ways, when a list is in the progress of
> introducing encrypted communication or for (other) testing purposes.
>  (b) A strict mode that keeps all the communication encrypted and won't
> ever send out mail without encrypting it.
> 
> The strict (b) mode should certainly be default, and
>>  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)
> is in fact essential for the application to make sense. By Optionally, I
> meant that it should be possible to not force encryption which would be
> the (a) mode of operation.
> 
> On 28.02.2016 04:48, Abhilash Raj wrote:
>>
>> I have a few small questions doubts about your features below...
>>
>>
>>> Some features could be:
>>>  1. Automatic pubkey collection from inbound mail
>>>
>>
>> What happens if I send a forged email with some user's email address as
>> FROM and use a fake key? Automatic public key collection isn't a very good
>> idea, you should be *very* careful about how you handle public keys.
> 
> The idea was to collect the public keys so an authority (list admin)
> could manually set their trust levels which would be necessary in strict
> (b) mode in order to use a key at all.
> 
> On 28.02.2016 04:48, Abhilash Raj wrote:
>>>  2. Outbound mail encryption and signature validation
>>>
>>
>> I would suggest you keep encryption as a part of extended goals in case of
>> GSoC. You'd be surprised how many students are not able to finish their
>> proposal in time.
> 
> I will try to make a realistic evaluation of what's possible in my GSoC
> before i apply.
> 
> On 28.02.2016 10:30, Stephen J. Turnbull wrote:
>>  >  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?
> 
> On 28.02.2016 04:48, Abhilash Raj wrote:
>> Shouldn't both be working differently? Encrypted
>> emails distributed as encrypted email and signed email distributed as
>> signed.
> 
> I paired them this way because outbound encryption and inbound signature
> validation requires the application to manage the subscribers public
> keys and inbound encryption requires the application to manage the lists
> keypair so I would probably implement 1. and 2. as well as 3. and 4. at
> the same time. 1-4 are part of the core functionality.
> My list is badly structured.
> 
> 
> 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.
> A user would have to have the public keys of all the subscribers at the
> time of sending a mail to the list and encrypt the mail for each of
> them. This would require modification to the client software for this to
> behave like a mailinglist, especially if subscribers join or leave the list.
> 
> A method for real end-to-end mailinglists is described in
> Practical Encrypted Mailing Lists by Neal H. Walfield, feb 2016 [1]
> but this is not what I want to do.
> Another alternative would be to have a pgp proxy outside the list server
> that does the re-encryption but this would not be as convenient as
> having a re-encrypting listserver.
> 
> Considering that all subscribers recieve the mail and usually listserver
> admins are subscribers theirselves, I think than an implementation where
> the listserver recieves a copy as well definitly has some uses.
> 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.
> 
> On 28.02.2016 10:30, Stephen J. Turnbull wrote:
>> 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.
> 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.
> 
> On 28.02.2016 10:30, Stephen J. Turnbull wrote:
>>  >  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?
> Trusted means that the key has been marked as trusted by an authority
> (list admin). The authority has to decide what actions have to be taken
> to mark a key as trusted. This could be exchanging fingerprints in real
> life or fingerprints could be confirmed by a trusted third party (eg a
> list member that already knows that public key).
> 
> On 28.02.2016 04:48, Abhilash Raj wrote:
>>>  5. A mailinterface for organizing the encrypted lists, subscribers
>>>     public keys and trust levels
>>
>>
>> I would like to know more on how you plan to do this.
> It could be one command to list all the pubkey fingerprints along with
> the corresponding subscriber email adress, the trust level and another
> command to set the trust level of a pubkey (by its fingerprint).
> This would require the list admin to securely identify, for example
> by pgp signing command mails.
> 
> I did not yet research how to implement mail commands.
> 
> On 28.02.2016 10:30, Stephen J. Turnbull wrote:
>> 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.
> 
> I'm not exactly sure what a threat model is. But a scenario this would
> protect from is eavesdropping on list communication by a mailserver – or
> anyone in case inter-mailserver communication or access to a mailbox
> isn't properly secured. A scenario where privacy could still be violated
> is when an eavesdropper gains access to the mailserver or any
> subscribers private key.
> 
> I don't understand, why would documentation be impossible?
> 
> [1]: http://hssl.cs.jhu.edu/~neal/encrypted-mailing-lists.pdf
> 
> Jonas
> _______________________________________________
> 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