Thank you Stephen. I agree with your points and I will make sure to clearly document any potential security pitfalls of the system for the users and to write a detailed and precise design plan that has special emphasis on security implications before I start coding this project.
However, at the moment I'm in the middle of writing my Project Proposal. May I send you a draft along with personal questions? And/Or Abhilash Raj, may I send you those? To make a first impression, I thought about writing a general blog post on the state of mailinglist/group communication encryption that covers the efforts toward encrypted lists in mailman. Could that work as a first impression instead of fixing a bug in mailman? The easier ones seem to get patched faster than I can catch up. Thank you again, Jonas On 29.02.2016 21:49, Stephen J. Turnbull wrote: > Jonas writes: > > > 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. > > It's true that keeping things secret from the server would be hard, > but at least in theory it would be possible to avoid decryption in > normal operation by having the originator use a "session key" and a > symmetric algorithm to do the actual encryption, and then using the > user's PGP key to encrypt the session key. Then all you need to do is > decrypt the session key and reencrypt it with the user's (or users') > key(s). > > If possible (I mean I suspect it requires privacy software that > doesn't currently exist) this would be nice because you don't have to > worry about having copies of decrypted text in memory, in swap, and in > temporary files.[1] Of course this would mean that such an MLM could > not decorate the mail with header or footer, but you probably should > not do that anyway because of limitations of MUAs and users in > displaying/interpreting indications of what portions of a message are > secure. > > > Considering that all subscribers recieve the mail and usually > > listserver admins are subscribers theirselves, > > In security, you either need to take care of the unusual case, or > document that the case is not covered. Wouldn't you rather have a > short list of "you can't use my software in these cases: ..."? > > > I think than an implementation where the listserver recieves a copy > > as well definitly has some uses. > > Copy of the encrypted message, maybe, although I would argue that > archiving should default to off for an encrypted list. But decrypted, > I disagree strongly, and would do my best to block integration of such > a feature (it's Barry's call in the end, not mine). If you really > want the server to have a decrypted copy, that is easily enough > accomplished by subscribing a decryption program to the list. Our > goal should be to do our best to reduce the additional attack surface > presented by the MLM by default, and leave the users to their own > devices in reducing security and increasing risk. > > > 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. > > If there's anything we know about users, it's that they only learn > about security when they experience harm from lack of it, and even > then few actually do anything effective about it.[2] Admins have > enough to worry about without drawing an arrow labeled "attack here" > on their system (running an encrypted list already paints a bullseye > on it). Whenever possible, we want random clueless behavior to *not* > result in a security hole. So yes, the private keys must be > protected. But as much as possible we should try to ensure that if > the list server is compromised, the communications are not. > > >> [Automated key generation is 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. > > I'm not talking about the availability of these basic facilities. If > the system doesn't have them, none of the necessary crypto facilities > will be available from Python anyway. I'm talking about the > introduction of unnecessary complexity. I don't know offhand how to > attack it. I'm saying that before we introduce additional complexity > we need to be pretty sure that it's hard to attack. > > If you want to do this, you need to learn the security mindset[3]. > Otherwise, you're very likely going to leave behind bugs that someday > will bite somebody who is earnestly trying to do the right thing. > > Back in the day, I set the config on Smail 3.1.0.99 to block outside- > to-outside relays, as recommended by the documentation. I was shocked > to be informed a few weeks later that my box was being used as an open > relay. Guess what? They documented that feature, but the > implementation was a stub until 3.1.0.101. > > > 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. > > Of course there has to be a private key usable by the list server > because the whole purpose of the exercise is to avoid distribution of > all keys to all subscribers. But stealing the keys is only one of the > many ways to get past a lock. We need to protect the hinges on the > other side of the door, too. The most effective way to do that is to > ensure they're not exposed in the first place. > > > > What does "trusted" mean? > > > Trusted means that the key has been marked as trusted by an authority > > (list admin). > > OK. > > > I'm not exactly sure what a threat model is. > > Find out! It's more than just a few random scenarios, I'll tell you > that much. > > > But a scenario this would protect from is eavesdropping on list > > communication by a mailserver > > How about one run by a subscriber? > > > – or anyone in case inter-mailserver communication or access to a > > mailbox isn't properly secured. > > You can assume that SMTP is unlikely to be secured. TLS is more > common nowadays but hardly universal. > > What makes you think that users won't save decrypted messages? You > need to document that as a threat and exclude it from those you can > protect against. > > > I don't understand, why would documentation be impossible? > > Users have a habit of assuming that "secure" (or whatever favorable > adjective is involved) applies to their use case. You need to be able > to describe the threats that are and are not defended against in > detail and very clearly. > > For example, one use case that has been brought up in the past is a > mailing list that contains private conversations among a group of > patients and the group therapist. But you can expect that in the case > of a multi-therapist clinic, they will want to share a single server > with a professional administrator. That server's admin presumably has > access to the list keys, but you don't want that in this use case, not > even if she is one of the therapists. > > Thus, you need to make it clear that this scenario (a server admin who > should not have access to the privileged conversations) is *not* > included in *your* threat model. Server admins are necessarily > trusted, and excluded as sources of security breaches. If you don't > clearly specify that threat model in your design, you're not going to > be able to document it well enough for users to understand. > > > Footnotes: > [1] Think "the disk was stolen". Private keys on that disk? Not > necessarily. What? That wasn't part of your threat model? Better > say so! > > [2] Consider how many people continue to use Windows! > > [3] https://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html > _______________________________________________ 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