[Mailman-Developers] GSoc - Requirement from Mentor to complete the project

[Abhilash Raj]

Consider this flow of message from one user to all list-subscribers:

 * A user sends a message( signed as well as encrypted )which as soon as
received by mailman is first queued in "IN" queue.

 * When the incoming runner wakes up the message is checked if it is for
owners, posting or encrypted.An encrypted chain is created  for
encrypted messages.

 * Now according to the use case there can be two encrypted chain:

	1) Where the posters are fully trusted and thus this rules only checks
the signature of a message. If a message signed by a member is received
it is sent to pipeline queue in a encrypted form for further processing.

	2) Where the posters are not fully trusted. In this case there needs to
be various checks on decrypted message like current default-posting-chain.

 * The messaged is moved in between queues in the encrypted form
encrypted by a symmetric key algorithm which uses list's secret key to
encrypt the message.

 * When the pipeline handler wakes up it decides which pipeline the
message is to passed through. In this case an encrypted_posting_pipeline
is created to process an encrypted message.

 * This encrypted_posting_pipeline is used to keep the message in
plain-text for a minimal time. The message is decrypted, headers and
footers are added and the message is signed by list's pub-key. It is
then again (symmetrically) encrypted and stored in the outgoing queue.

 * The outgoing runner personalizes each message by encrypting it with
each user's pub key and forwards it to MTA using VERP(Variable Envelop
Return Path).


Now consider the threat models it addresses.

Firstly this verifies the integrity of the message. This is done by
verification of signature and matching that sender's address indeed
matches the address in signature so that you can sure that message was
indeed sent by the sender.

Secondly this maintains the confidentiality of the message. Even if the
message is intercepted it can only be read by the one whom it is
addressed to.

There are the threats this does not address:

If the keys/system/MUA of a user sending or receiving the message is
compromised or contains a virus, no assurance can be provided about the
integrity or confidentiality of the message.


On Tue, May 7, 2013 at 8:27 AM, Stephen J. Turnbull <stephen at xemacs.org>
wrote:
> Abhilash Raj writes:
>
>  > Let me divide the project in a few pieces so that each can be
>  > discussed upon separately.
>
> This is a good idea, but you should take them up one at a time, unless
> you have a good approach and are expecting "sounds good, get started"
> as the reply to that point.
>
>  > * Firstly a utility to encrypt or decrypt the message. Well i found
>  > [python-gnupg][1] for this purpose and would try to write a wrapper
>  > around it for the use by mailman. But I found another option for it
>  > [GnupgInterface][2]. GnupgInterface was used in the
>  > [mailman-pgp-smime][3] patch for mailman and also has options to sign
>  > and encrypt in one call of a function( unlike python-gnupg ). If
>  > anyone has ever used any of these two would you please suggest which
>  > one is better?
>
> This isn't first.  Don't be so eager to write code when you have not
> stated the requirements with any precision.
>
> *First* you need to describe the life of a message from a thought in
> the sender's mind until it hits the receiver's eyes.  (It could
> actually be somewhat shorter than that, but these endpoints ensure
> you'll get everything we need somewhere in between.)  Which steps are
> required for every message?  Which are optional, depending on the list
> policy and/or user choices?  Which are implemented in Mailman?  Which
> in MTAs/MDAs?  Which in MUAs?
>
> You also need to decide what threats this process is suppose to
> protect the users from.
>
> The combination of these two will determine what Mailman needs to be
> able to do with incoming and outgoing posts.  Then you need to see
> what Mailman already does perfectly, what needs to be modified, and
> what needs a new implementation.
>
> This description of requirements doesn't need to be as authoritative
> as Scripture, but we need something fairly detailed to start with.
>
> Once that's done, we can talk about implementing crypto operations.
> But I don't think it matters much which module you start with.  (Why
> not?  The answer is a general concept of software engineering.)
>
>  > * The point of encryption and decryption in the various queues. I was
>  > of the opinion that the message is decrypted as soon as it enters the
>  > IN queue and while its about to leave the queue it is encrypted with a
>  > symmetric key algorithm using the list's secret key. And then it is
>  > subsequently decrypted in the next queue and finally in the OUTGOING
>  > queue it is signed and encrypted with each user's pub-key.
>  > Any suggestions about this?
>
> I think the concerns about decrypted material hitting disk are valid.
>
> Therefore I would recommend that you avoid decrypting until necessary.
> (It may not even be necessary.  When?  What exactly do I mean by "not
> decrypting"?  This requires a good understand of the OpenPGP format,
> as well as Mailman queue processing.  Don't hurry, feel free to ask
> questions -- as long as they don't amount to "I don't know, tell me"!)



-- 
Abhilash Raj