PGP support for MM3
Hello everybody,
I'd like to see PGP support for MM3 but I thought it might be a little to early to file an issue.
My original motivation was a setup of a full encrypted mailing list. I'm well aware of the fact that it provides not the security a full end-to-end encrypted communication provides, but for some people (including me) it is an acceptable compromise.
Encrypted mailing for groups of people is still a mess in 2016:
- Either the group is relatively static or you never encrypt the mail for all people.
- All members need to know each other. And you need the keys of all the other members.
So far for the motivation. Below there are some initial thoughts:
**Treat mail differently based on their signing status:**
- Whether it has a signature or not.
- Whether the signature is valid or not.
- Whether the signing key matches the key of the list member.
**Treat mail differently based on their encryption status**
Whether it is encrypted or not.
**Other opportunities**
- A public key per list.
- Signing of outgoing mails with that list key.
- Encryption of outgoing mails with that list key.
- Send a mail with the lists public key on request.
Which one of these points a worth an implementation?
Regards
Dominik
On 11/18/2016 07:26 AM, Dominik wrote:
I'd like to see PGP support for MM3 but I thought it might be a little to early to file an issue.
There are threads on a potential GSOC proposal for this starting at <https://mail.python.org/pipermail/mailman-developers/2016-February/025420.ht...> and <https://mail.python.org/pipermail/mailman-developers/2016-March/025621.html>.
I seem to recall more about this or maybe other GCOC proposals in this area, but I don't know the status of any of it.
Steve may be able to provide more info.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
On 11/18/2016 07:26 AM, Dominik wrote:
I'd like to see PGP support for MM3 but I thought it might be a little to early to file an issue.
It's too late. :-) The issue has already been raised, years ago. So far the complexity has deterred people from actually doing anything about it. (I hasten to add it's not *that* hard, it's just that so far everybody except our GSoC students who has proposed adding crypto to lists has balked at the idea that you actually have to think about your threat model, and gone away at that point.)
Which one of these points a worth an implementation?
All of them. Individually and in various combinations. And that's the problem from our point of view. If somebody would tell us *what* they want, do a lot of the work on identifying threats, and maybe do a coding, we could provide the *how* and help do implementations one at a time. But we don't have itches to scratch ourselves, and plenty to do besides building a better mousetrap when the customer has a cockroach problem.
Steve may be able to provide more info.
Abhilash Raj actually worked on the "signed list" GSOC project. I don't know if he's still interested in that particular project but I believe he maintains his interest in security. I hope he'll get involved in the conversation. (It may be a couple of weeks, though, I know he's facing deadlines at school.)
As Barry mentions in a parallel response, at least at the present time, there is no good theory of security that would allow us to provide a single, simple "crypto-enabled list" configuration, or set of options. Rather, due to the nature of email, there are a very large number of use cases and corresponding threat models, and each requires a unique configuration.
Picking one or more and getting started on implementation, and especially user documentation, would be welcome. Aside from Abhilash's work, we also have this summer's work on Authenticated Received Chain (ARC) by Aditya Divekar that uses crypto technology, but it's a very special use case, and has some really smart IETF people behind it so it's well-defined.
It's the definition of use cases and threat models that users would like us to address that is the main task now. Once have that, we can start building up the components for handling keys and various signing and encryption configurations. Steve
On Nov 18, 2016, at 04:26 PM, Dominik wrote:
I'd like to see PGP support for MM3 but I thought it might be a little to early to file an issue.
I think full PGP support as many people want will be a multi-issue, multi-branch effort. For example, I can imagine a branch that enables list-specific key management so that you can encrypt a message to a mailing list. Then users/addresses would each also have key management. Those touch the database layer. There will probably be branches that touch the REST API, and handler/rules, etc. Then there are likely changes to Postorius, possibly HyperKitty, etc.
Encrypted mailing for groups of people is still a mess in 2016:
- Either the group is relatively static or you never encrypt the mail for all people.
- All members need to know each other. And you need the keys of all the other members.
So far for the motivation. Below there are some initial thoughts:
**Treat mail differently based on their signing status:**
- Whether it has a signature or not.
- Whether the signature is valid or not.
- Whether the signing key matches the key of the list member.
**Treat mail differently based on their encryption status**
Whether it is encrypted or not.
You could certainly do these things. Once the basic key management infrastructure is in place, you could fairly easily add various rules and handlers to effect some of these features. E.g. a rule could say "if this message does not have a valid signature, discard it". That could be useful even without full encryption. For outgoing encryption, you'd need a pre-MTA handler if you wanted to do personalization, e.g. encrypt the message to each user's registered key.
**Other opportunities**
- A public key per list.
- Signing of outgoing mails with that list key.
- Encryption of outgoing mails with that list key.
#2 and #3 could be done with list-wide handlers, since they aren't personalized.
- Send a mail with the lists public key on request.
Fairly easy to add a command to do this.
Which one of these points a worth an implementation?
All? None? Some? :)
It really kind of depends on what people want. At a minimum, I would really like the option of running a mailing list which requires valid signatures for posting, to avoid blindly trusting the sender headers. That still requires user-based key management, so perhaps that's a good place to start.
Cheers, -Barry
participants (4)
-
Barry Warsaw -
Dominik -
Mark Sapiro -
Stephen J. Turnbull