Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
On Mar 23, 2017, at 12:06 AM, Stephen J. Turnbull wrote: >FYI: Encrypted lists *are* occasionally requested. Another possible use case would be attempting to prevent the wholesale compromise of email storage. Meaning, if you keep your email on some external server, and that server is compromised, if those messages are encrypted, then at least they likely will be very difficult for the attacker to decrypt since the keys won't likely be colocated with the emails. Sure you can probably phish specific individuals, but it won't be "crack the server and now you have a million secret messages". It's the same as with encrypted person-to-person messages (which almost no one uses because Reasons). >You have my permission to say "I told you so" if we're forced to >abandon this as a silly idea. Until then, I think you're wasting >bandwidth in opposing it from the get-go. Once again, I'd be happy to >hear where our threat models are deficient once we start to talk about >them. But none of the proposals so far have really identified a >threat model let alone a corresponding use case! So there's nothing >to criticize yet. I should state for the record that my personal interest in this feature isn't so much encrypted mailing lists per se, but the architectural and design pressure it will put on Mailman 3, and our responses to that. Encrypted lists are the kinds of things I want to make possible with Mailman 3, so the APIs, hooks, configurations, and plugins that would be needed to implement encrypted lists (assuming, IMHO correctly that they won't be integrated into the core) will be of use to others who want to do Interesting Things with mailing lists. Cheers, -Barry ___ 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
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
On Mar 21, 2017, at 07:27 PM, Stephen J. Turnbull wrote: >Not if the target membership isn't already paranoid. Remember, >20%-40% of devices are already compromised. Even at the low end, >assuming uniform draws, with *three* members odds are *even* that one >is compromised. Is anybody even aware of any mainstream mobile email readers that support encryption? Or webmail interfaces? I seem to remember a recent announcement that Gmail will soon be supported plugins that could be used to read and send GPG/PGP encrypted messages. An encrypted mailing list won't help you much regardless of the compromised nature of your device if you can't even read the encrypted messages. ;) -Barry ___ 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
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
On 03/22/2017 04:02 PM, Stephen J. Turnbull wrote: > Also references to existing knowledge would be appreciated, such as > "zero knowledge" schemes that might allow untrusted root on Mailman > host, and the various implementations like SELS that have been > mentioned. In my proposal [1 or 2], I concluded that a SELS like proxy encryption scheme doesn't apply well to Mailman's existing infrastructure as well as the stated requirements in the project idea. -Jan (Just to note, I have recently updated my proposal, make sure to have the latest version) [1]: https://neuromancer.sk/page/gsoc/mailman#technical-details [2]: https://neuromancer.sk/static/mailman.pdf signature.asc Description: OpenPGP digital signature ___ 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
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
On 03/22/2017 04:06 PM, Stephen J. Turnbull wrote: > Rich Kulawiec writes: > > > (In the specific case, e.g., the right people using the right > > devices with the right knowledge and self-discipline: maybe. But > > there are not many of those cases and any of them can revert to the > > general case in seconds with one poor decision or perhaps even > > without one.) > > I'm with Richard Damon on this. > > FYI: Encrypted lists *are* occasionally requested. Even if we are > forced to give up, we need to investigate this, and convince ourselves > that there really are NO valid use cases so we can make the case that > it's a bad idea to those users. I note that several other projects > have created variations on encrypted lists. It's reasonable for us to > want to learn what they are and are not good for in order to converse > with users about their requests for encrypted lists. > > You have my permission to say "I told you so" if we're forced to > abandon this as a silly idea. Until then, I think you're wasting > bandwidth in opposing it from the get-go. Once again, I'd be happy to > hear where our threat models are deficient once we start to talk about > them. But none of the proposals so far have really identified a > threat model let alone a corresponding use case! So there's nothing > to criticize yet. A use case I have in mind is for mailing lists that: a) have a relatively low number of subscribers. b) have or can establish some sort of a PGP web-of-trust, in a sense that a subscriber has to trust the list owner's key or the list key, and that the list owner has to trust the subscriber's key when accepting his subscription. (this is due to fairly strong assumptions about attacker's abilities) c) can be anonymous (apart from obvious information stemming from b) and no other info about subscriber's or sender's identity has to be disclosed to other subscribers than what is now with anonymous lists. (see Technical details in my proposal) This is what my proposal is aiming for and what I think is a realistic application of encrypted mailing lists. -Jan signature.asc Description: OpenPGP digital signature ___ 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
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
On 03/21/2017 11:16 PM, Rich Kulawiec wrote: > On Tue, Mar 21, 2017 at 04:04:20PM +0100, johny wrote: >> Shifting the attacker to actively compromise devices is an overall >> improvement. > > If "compromising devices" was difficult, I might agree. But it's not. > Devices of all descriptions have been and are being compromised in > enormous numbers on an ongoing basis even by relatively unskilled > attackers -- since they can buy/lease the requisite tools and infrastructure > and use them without needing to understand how they work. > > I think you (and others) are continuing to badly underestimate the > scale at which this is taking place. We're not talking about an > ecosystem in which 2% or 6% of devices are compromised; we're talking > about one in which any estimate under 25% should be laughed out of > the room and an estimate of 50% should be given serious consideration. > (I think the latter may be still be too high. But it's certainly > within the realm of plausibility.) We're also talking about an > ecosystem in which, increasingly, vendors are shipping devices that > are essentially pre-compromised at the factory due to very poor > and entirely self-serving design and implementation decisions. Before introducing encryption during transport an attacker had a choice to either sniff traffic or compromise a device. Plugging one hole, encrypting the transport, *MUST* be an overall security improvement, it will not be only in some edge circumstances. I think that the percentages you are presenting are not the right ones for what you could expect from users of a GPG encrypted mailing list. a) The fact that they are even considering to subscribe to an encrypted mailing list, that they have a GPG keypair moves the probability that they are doing this on a compromised device way lower. (at least I think so, I don't have any concrete data) b) You are assuming that the percentages you give are actually all one homogenic attacker, aimed at gaining access to an encrypted mailing list, having the capabilities to do so and having control of X% of devices. No such one attacker actually exists. >> There are plenty of threat actors for which sniffing traffic to a >> plaintext mailing list might be easy, however overcoming a well setup >> encrypted mailing list system would be quite hard. > > I don't think so, if the mailing list is of sufficient size. (Certainly > one with only a handful of people might be hard to crack, but that > would be fairly hard today even without encryption.) > >> The system security only increases in this case. It's security is >> obviously debatable against state actors/equivalent threats, there it >> might not improve much, but improves significantly against other threats. > > State actors are not necessarily the biggest threat. They might > have the most resources, and they might have the best cryptographers, > and they certainly have the most political power (e.g., NSLs in the US), > but they also have their own areas of focus and this may not be one of them. > > If there's money to be made by trafficking in information, then others > will take an interest. They may not have the resources, cryptographers, > power, etc., but they do have some very talented personnel, stockpiled > exploits, and rather a lot of experience with mass compromise of end > user systems. These are not script kiddies in mom's basement, these > are professionals with the discipline to identify and attack targets > successfully on a large scale. Don't underestimate them. *That* > particular mistake was already made by every ISP on this planet ~15 > years ago, which is one of the major reasons the problem has the > scope that it has today. I still think that there is a security improvement that outweights the drawbacks. Of which two were noted: a) Mailman's encrypted mailing list security will be over-estimated by naive users that will get bitten by this. This is valid for cases where the users aren't already communicating in an insecure way (which is likely), so only covers a small userbase and can be tried to be mitigated by proper warnings, documentation, common sense. (As many E2E and similar apps do, or should do, warn that endpoint security is important and that endpoint compromise is catastrophic) b) Added complexity, maintenance cost to Mailman's infrastructure. This can be mitigated by implementing encrypted mailing lists either as a plugin as was proposed here before, or just by making the feature as non-intrusive into Mailman's infrastructure as possible . (which I think is doable if the proposal aims to do so) -Jan signature.asc Description: OpenPGP digital signature ___ 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:
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
Rich Kulawiec writes: > (In the specific case, e.g., the right people using the right > devices with the right knowledge and self-discipline: maybe. But > there are not many of those cases and any of them can revert to the > general case in seconds with one poor decision or perhaps even > without one.) I'm with Richard Damon on this. FYI: Encrypted lists *are* occasionally requested. Even if we are forced to give up, we need to investigate this, and convince ourselves that there really are NO valid use cases so we can make the case that it's a bad idea to those users. I note that several other projects have created variations on encrypted lists. It's reasonable for us to want to learn what they are and are not good for in order to converse with users about their requests for encrypted lists. You have my permission to say "I told you so" if we're forced to abandon this as a silly idea. Until then, I think you're wasting bandwidth in opposing it from the get-go. Once again, I'd be happy to hear where our threat models are deficient once we start to talk about them. But none of the proposals so far have really identified a threat model let alone a corresponding use case! So there's nothing to criticize yet. Regards, Steve ___ 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
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
Richard Damon writes: > One big thing that I haven't seen in the discussion of this problem is > exactly WHAT issue/problem this feature is intended to solve, There are > several different problems that encryption can help with, each needing > different sort of support from the software. Yup, and I've been telling the prospective interns that throughout. But Rich Kulewiec is right that many or most of them can be eliminated right off. For example, I don't see any point in actual end-to-end encryption, as that would require everybody to know everybody's keys. OK, so we could create a PKI for each list, but that's effort over and above the encryption module, probably not appropriate for this GSoC. (It's been mentioned that algorithms are not forever, but similarly I think that's out of scope.) AFAICS, this means that root on the Mailman host is trusted, and needs to know the session key for each message. Perhaps you can avoid having to trust list owners, but when does that scenario actually make sense? Note that GSoC is Google Summer of CODE - the reason for being cagey about what I'm thinking about as specs and use cases is not that the intern will be responsible for design. It's that the intern needs to understand that design and the use cases it serves in order to determine whether the implementation is correct, write tests, and so on, and I prefer to mentor Socratically. That doesn't mean anybody else needs to be coy! Feel free to put your ideas about use cases out there. Also references to existing knowledge would be appreciated, such as "zero knowledge" schemes that might allow untrusted root on Mailman host, and the various implementations like SELS that have been mentioned. Steve ___ 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
