Project idea understanding
Dear Mentors,
After going through a lot of sources mentioned in recent replies to other subscribers and some online sources i have got some understanding about the idea, which i would like to share with you guys and get some feedback and suggestions .
I think we can encrypt the list in the following ways (broadly speaking):
Each message will be encrypted with all users as recipients. The mailing-list maintainer will have to regularly send the list of recipients over the mailing-list itself, so that every user comes to know the public keys of all recipients. But this way the maintainer will have to send recipients list to a large number of users.
Another way could be relaying each message through the maintainer. The maintainer then encrypts it for single recipient. This might solve the problem of sending messageto large number of users but it increases latency (each message must wait for the maintainer to process it) the maintainer can censor each message as they all are relayed through him.
Or instead of using asymmetric keys we use a password given to all users.
I have attached an image in hopes of conveying my idea more clearly for points 1 & 2.
Also I'm still not finished with the book "Thinking Security - Steven M. Bellovin" mentioned by Stephen in one of the replies, so i hope to refine this crude idea in future.
The Python GSoC page says that every student must maintain a blog which i have been maintaining at : Parseltongue.pythonanywhere.com
On 03/10/2017 02:08 AM, raditya wrote:
There has been a GSoC project like this in the past and there was quite some discussion on the mailing list. https://www.mail-archive.com/search?q=encrypt&l=mailman-developers%40python.org
raditya writes:
You are way ahead of yourself. Before thinking about *how* to manage an encrypted list, both operationally and socially, we need to decide
(1) *who* is going to be posting (2) *why* are they posting to an encrypted list (3) *who* is going to be subscribing to such a list (4) *why* are they subscribing (5) *who* the traffic is being hidden from (6) *what capabilities* the adversary may be expected to have (7) *who* will be managing the list and host (8) *the trustworthiness* required of list and host managers (9) *what other features* are required in view of (1) -- (8), such as anonymity
and there may be some other basic features to consider. I strongly suggest a close look at RFC 5598 "Internet Mail Architecture" to get a good understanding of the "players" in the game of "mailing list". Then we need to talk about what threats encryption can protect against, what threats other parts of Mailman can protect against, and what can't be protected against. Documentation will eventually be the hardest part of this task. Although the GSoC intern won't be responsible for perfecting it, documenting the threat model is going to be important both for the users (subscribers and list owners) and for the design and implementation.
Don't worry about starting with a narrow use case, limited to some "user story" you personally are familiar with. We can think about generalizing as we go along, or as a follow-on after the project is done. Original design and maximum generality are not required of a GSoC project (although working on the design yourself does help with planning implementation). Also, I have a lot of ideas about "generic" threats, and will reveal them gradually as we go along. But it's important for you to get over the idea that encryption itself is a big deal. It's not, and the basic mechanisms are already in place (for signing, but it's quite similar) from a previous project.
Regarding your suggestions so far, I can tell you already that there are technical or "audience" problems with your initial ideas.
As you seem to recognize, and Simon also points out, this is not an attractive UI for many scenarios, including "large" lists and non-technical posters. And it's already possible in any case for users competent in such operations.
This is not going to be done by a human, there will be some kind of Handler (and probably a Rule) to deal with it.
"Censoring" (eg, anonymization, as well as moderation) is a *good point*, whose general application I missed above. This is non-trivial for secret traffic in some cases. Some of it can be automated, and in some applications all of it should be. "Hold that thought." :-)
Again, not an attractive solution. Consider the "secret" distribution problem in general, and especially the revocation problem if you decide to kick somebody off the list. The primary goal here is to avoid forcing subscribers and posters to learn about encryption and security. We probably can't avoid some burden on the users, but the less the better -- we know very well from the security problems that become public every day that users are not very good are secure usage.
I hope this helps you get a better handle on the scope of this project.
Regards,
Steve
On 03/10/2017 02:08 AM, raditya wrote:
There has been a GSoC project like this in the past and there was quite some discussion on the mailing list. https://www.mail-archive.com/search?q=encrypt&l=mailman-developers%40python.org
raditya writes:
You are way ahead of yourself. Before thinking about *how* to manage an encrypted list, both operationally and socially, we need to decide
(1) *who* is going to be posting (2) *why* are they posting to an encrypted list (3) *who* is going to be subscribing to such a list (4) *why* are they subscribing (5) *who* the traffic is being hidden from (6) *what capabilities* the adversary may be expected to have (7) *who* will be managing the list and host (8) *the trustworthiness* required of list and host managers (9) *what other features* are required in view of (1) -- (8), such as anonymity
and there may be some other basic features to consider. I strongly suggest a close look at RFC 5598 "Internet Mail Architecture" to get a good understanding of the "players" in the game of "mailing list". Then we need to talk about what threats encryption can protect against, what threats other parts of Mailman can protect against, and what can't be protected against. Documentation will eventually be the hardest part of this task. Although the GSoC intern won't be responsible for perfecting it, documenting the threat model is going to be important both for the users (subscribers and list owners) and for the design and implementation.
Don't worry about starting with a narrow use case, limited to some "user story" you personally are familiar with. We can think about generalizing as we go along, or as a follow-on after the project is done. Original design and maximum generality are not required of a GSoC project (although working on the design yourself does help with planning implementation). Also, I have a lot of ideas about "generic" threats, and will reveal them gradually as we go along. But it's important for you to get over the idea that encryption itself is a big deal. It's not, and the basic mechanisms are already in place (for signing, but it's quite similar) from a previous project.
Regarding your suggestions so far, I can tell you already that there are technical or "audience" problems with your initial ideas.
As you seem to recognize, and Simon also points out, this is not an attractive UI for many scenarios, including "large" lists and non-technical posters. And it's already possible in any case for users competent in such operations.
This is not going to be done by a human, there will be some kind of Handler (and probably a Rule) to deal with it.
"Censoring" (eg, anonymization, as well as moderation) is a *good point*, whose general application I missed above. This is non-trivial for secret traffic in some cases. Some of it can be automated, and in some applications all of it should be. "Hold that thought." :-)
Again, not an attractive solution. Consider the "secret" distribution problem in general, and especially the revocation problem if you decide to kick somebody off the list. The primary goal here is to avoid forcing subscribers and posters to learn about encryption and security. We probably can't avoid some burden on the users, but the less the better -- we know very well from the security problems that become public every day that users are not very good are secure usage.
I hope this helps you get a better handle on the scope of this project.
Regards,
Steve
participants (3)
-
raditya -
Simon Hanna -
Stephen J. Turnbull