Hello,
Here's what I propose(of course deeply inspired from abhilash and
schneuder) :-
1)A list owner creates a key-pair, and also a passphrase(to protect LIST's
secret key,may be using gnupg, more on that later ).Here ,if we want, can
raise the security standards by using gpg-agent(to manage security-key and
its passphrase,it leads to some hardware token like cryptostick).
2)Now when a user subscribes, he will upload his public-key(may be through
some interface on postorious),now the owner can decide his subscription(may
be based on some write-up).Then he sends the LIST's public key to user.
3)Now each time, when user needs to post something, he has to sign it using
his private-key and encrpyt using List's public key(signing would reduce
spam).
4)Now mailman checks the signature with public-key(if failure occurs, can
bounce it back),now first it signs it using LIST' secret key (here
gpg-agent comes to play,only the owner can do this using the passphrase)
and can be sent to the users after encrypting using their respective public
key.Here we need to ensure one thing that the message never remains in
decrypted form on Mailman server(which is done by that whole secret
key-passphrase thing).
5)Now the user can verify using list's public key,and can henceforth
decrypt the message using his private key.
I would like to point out that the message would never travel decrypted and
while the owner accesses it appropriate censorship could be applied(as
pointed by raditya).
Now I would like to know(specifically) what are some other threats,which
could effect this and any difficulties with implementation.
Send Mailman-Developers mailing list submissions to
mailman-developers@python.org
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.python.org/mailman/listinfo/mailman-developers
or, via email, send a message with subject or body 'help' to
mailman-developers-request@python.org
You can reach the person managing the list at
mailman-developers-owner@python.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Mailman-Developers digest..."
Today's Topics:
- Project idea understanding (Stephen J. Turnbull)
Message: 1
Date: Sat, 11 Mar 2017 16:58:33 +0900
From: "Stephen J. Turnbull" <turnbull.stephen.fw@u.tsukuba.ac.jp>
To: raditya <raditya@iitk.ac.in>
Cc: Mailman-Developers@python.org
Subject: [Mailman-Developers] Project idea understanding
Message-ID: <22723.44585.967029.696464@turnbull.sk.tsukuba.ac.jp>
Content-Type: text/plain; charset=us-ascii
raditya writes:
- Each message will be encrypted with all users as recipients.
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.
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.
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.
- 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.
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." :-)
- Or instead of using asymmetric keys we use a password given to all
users.
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
Subject: Digest Footer
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
End of Mailman-Developers Digest, Vol 335, Issue 9
Bhavishya Desai