[Mailman-Developers] GSoC Project: pgp plugin

[Jonas]

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?

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.

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?

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