GSOC Proposal

mailman_proposal.md

##Introduction To consider the problem of signing and email-encryption using pgp/smime we must consider a few things first:

• What is the main purpose to sign/encrypt the email messages on a list?
• How are we going to implement this feature? Which kind of digital signature, which standards, which kind of encryption will be used for this purpose?
• What possibly could go wrong with the system? What problems may arise as a result of this feature for the list managers/users?

I will try to answer these questions in best possible way in my proposal.

##Need for such feature? Well a simple one line answer to this question is why send a message in 'postcard' if you can send it in an 'envelope'. A encrypted message is like envelop which only the intended receiver can open and view. Also even in the message passes though various insecure transmission gateways, the message is kept intact and safe. Also a signed message certifies that the message was indeed sent by the user. If someone tries to change the content on the message the signature becomes invalid and the receiver may then discard it.

This can also be used to create anonymous mailing lists where the from part is stripped from the mail so that the list members know that the message is indeed from a certified member of the group(meaning it can be trusted) and is also anonymous. For this once the email is received the signature is verified and then it need not follow the usual procedure of all the filters and may be directly sent.

##How will this work? This part is a step by step description of the process.

• When user subscribes to a list he uploads his pub-key to the server. After signing up for the list a mail is sent to the subscriber with the pub-key of the list(alternatively key could be provided for download at the intercface where he submitsd his pub-key). A user may later on add more keys via postorious or email. Each key is verified by sending an email to the key the email verifies.

• All the mails sent by the user to the list will be signed with his private key and then encrypted with list's pub-key(as per pgp standard). However this is just an option for the list-owner to force encryption/signing/both, he may allow only signed cleartext-message for the purpose where encryption is not required.

• Mailman decrypts and mail, checks the signature with users pub-key and if everything is right it signs the mail with the list's secret-key and encrypts the mail with per-user pub-key.(though I haven't drawn any conclusion on which one is best in this case- to encrypt and sign or sign and encrypt the message)

• Incase the signature is not verified mailman sends an unencrypted reply to the sender asking him to sign the message or manage keys by adding or removing the keys.

##Which parts of mailman will be affected?

Mailman core, where all the encryption decryption will take place. Also changes to the schema to add the pub-keys and changes in rest-api will be needed.

Mailman.client, add rest-api to add/remove pub-key of each user from postorius.

Postorius, where the ui will be there to add/edit the pub-key of a signed in user.

##Some corner cases!

• The message will at least be exposed to mailman since the message passed through various queues(encrypted in the incoming queue, cleartext in the moderation queue, cleartext in the outgoing queue). It gets decrypted in the IN queue where as it gets decrypted in the OUTGOING queue. During the movement of message in between these queues cleartext message is stored on the disk which creates a security threat where a third party plugin or virus could extract message. To address this problem the message after decryption (and deciding if the message is to be sent to subscribers) is re-encrypted using a symmetric key algorithm the key of which is the list's secret key.

• In case of a unverified signature or message that can't be decrypted the message bounces but notification is sent to list-admin and the poster about it.

• The encryption standard used here may not be supported by all the MUAs available especially the one in windows, but what we are trying to address is a problem of secure through-the-mail channel for communication, if one wants to join such list he should have a required environment.(There are available plugins for webmail clients and windows based MUAs to implement OpenPGP encryption and signature, ex: enigmail for mozzila clients)

• There would be options for list-admin to either force encryption, force signing of posts or both. However he may choose to implement none of these like a normal mailing list today in mailman.

• Signer and sender of a message may be different. This may be common in real life but only those messages will be accepted where the singer and the sender are same.

• The digest and archiver options are not available for these encrypted mailing lists.

##Encryption/Decryption standard

The choice of message encryption and decryption is very important for the fact that is should be supported by majority of MUAs, should be easy to implement and must be secure. OpenPGP and SMIME are the two standards known for this purpose. Although both standards are based on public-key encryption, both differ each other in the way they trust the keys(i.e. the user with a key). Also sometimes a combination of both OpenPGP and SMIME is used for enhanced security. So there are four choices for signing/encrypting emails:

• OpenPGP - assembles a "Web of trust". The Web of Trust represents the basic structure of the non-hierarchical Internet and its users. For example, if User B trusts User A, then User B could also trust the public key of User C, whom he does not know, if this key has been authenticated by User A.

• SMIME - your key must be authenticated by an accredited organisation before it can be used. The certificate of this organisation in turn was authenticated by a higher-ranking organisation etc. - until we arrive at a so-called root certificate.

• First OpenPGP then SMIME encrypted.

• First SMIME then OpenPGP encrypted.

I am going to use OpenPGP for this purpose because of the following reasons:

• SMIME certificates are paid as compared to OpenPGP which is a free open-source software.

• If you use a smime-certificate your issuer has a copy of it and in some extreme cases the privacy of your emails may be compromised. OpenPGP is entirely based on certificates generated by user so there is no question of loss of privacy( unless of-course your key is broken by a brute force attack in near future )

• More importantly, OpenPGP is a free and open-source and is constantly subjected to peer review. This means that any security loopholes or issues are quickly found and reported widely, ensuring you and your data is as safe as possible.

Encryption/Decryption Process

• A user signs the message with his secret-key(that he has already added on mailman) and then encrypt with the pub-key of the list he is sending to(which he gets to download at the point of subscription).

• When mailman receives the message it decrypts the message and tried to verify the signature using each pub-key(we might add an option for default key,which will be used first, for faster computation) of the user in the "From" field. If the signature is verified then it does not goes through rest of the pipelines and processing as usual(verification for sender as a member, spam filtering etc) and is marked as approved and sent to outgoing queue.

• The message moves from one queue to other queue in encrypted format using a symmetric key encryption algorithm, the key of which is the list's secret-key.

• When in outgoing queue it is signed by the list's secret-key(whose pub-key is with the user) and then is encrypted with each user's pub-key.

• User receives the message decrypts with his secret-key, verifies signature with list's pub-key that he has and finally reads the message.

##Key management

One of the biggest issues of any cryptographic procedure is to secure and manage the keys. Firstly for the lists, when the list is created by the owner he is asked to upload a secure keypair and enter its paraphrase.The keypair is not generated by mailman as its difficult to create enough randomness, which is required to create a secure key, on virtualised systems. The key is then stored in the database in secured form. We use gnupg-agent to handle paraphrases. It securely and conveniently stores paraphrases and gnupg can access the paraphrases whenever required and hence paraphrase and decrypted key is stored only in the memory during computation.

The pub-keys added by the users will be stored in different table(having many to one relationship with users) and will be used whenever there is a need to encrypt or verify_signature.

##Probable Implementation

Roughly these are a few files where changes will needed to be done so as to incorporate the encryption and decryption. This is just a small idea and may need a lot changes to reach production stage.

• utilities/encryption.py - This will be a new files under utilities to encrypt_data, decrypt_data, sign_data, check_signature, sign_encrypt_data, check_sign_decrypt_data.

• rules/moderation.py - This module works under "rules" pipeline which decides if a message will be distributed, held or rejected(bounced). The decryption and signature_verification will occur in this module and after that message will be moderated weather it will be distributed, held or bounced. A message whose sender address does not match the address in the respective key will also be bounced in addition to the rules in existing mailman.

• handlers/to_outgoing.py - This module maintains the outgoing-queue. The signing of the email and re-encryption with the per-user pub-key will take place here.

• Other "handler" pipelines modules to check that decrypted messages are handled properly and not held in clear-text format or sent to archives.

Also for the purpose of encryption/signing a python wrapper for the gnupg will used called python-gnupg. This module allows easy access to GnuPG's key management, encryption and signature functionality from Python programs.