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@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 _______________________________________________ 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
