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 link1 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.
- 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 strict (b) mode should certainly be default, and 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:
- 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:
- 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:
- Outbound mail encryption and signature validation
- 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.
- A mailinterface for organizing the encrypted lists, subscribers public keys and trust levels
- A webinterface
These too are out of scope. Again, security implications are unclear.
- 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
On 28.02.2016 10:30, Stephen J. Turnbull wrote: life or fingerprints could be confirmed by a trusted third party (eg a list member that already knows that public key).
- 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
On 28.02.2016 04:48, Abhilash Raj wrote: 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?
Jonas
Mailman-Developers mailing list Mailman-Developers@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%40g...
Security Policy: http://wiki.list.org/x/QIA9
-- thanks, Abhilash Raj