Just to put my two cents in...
On 2026-02-24 04:00, Stephen J. Turnbull wrote:
Yassin ElBedwihy via Mailman-Developers writes:
> I'm curious: What's the plan for implementing forward secrecy?
I have none. The mailing list needs to know the private key in order
to reencrypt the session key for the subscribers. It needs to
distribute the public key to senders somehow. If that is done on a
per-post basis, the distribution mechanism has to be implemented *in
Mailman* with some kind of authentication for senders. Then that
needs to be integrated with the senders' mail clients, somehow. There
would need to be at minimum a proof of concept for some MUA. Key
distribution is a bigger project than the mailing list changes, I
suspect.
The closest concept that has done this in the past is the use of GPG
encryption, both to *send* to the list and to *receive from* the list.
Whereas, a list would, upon "secure list" being selected, public
archives are disabled, and the system will:
(1) Generate a GPG key for the list itself
(2) Make that GPG key available for list subscribers on the list's info page
(3) Process list messages on whether the message was received as
encrypted or not.
(i) If the message was sent Encrypted, then only resend to individual
list members who have specified a GPG key on their profile/account (and
admins can set this if they have the user's key). People without keys
known to the system will simply never receive the message.
(ii) If the message was sent Plain Text, then resend to all without
encryption.
(iii) Lists can have an option for "enforce encryption" which would
Discard all Plain Text messages.
The closest thing I am aware of that used to do this was a tool called
Trident, which was designed to work as a secure enclave tool
(https://github.com/tridentli/trident) that had this built in as part of
its list functionality (however this was "home grown" project at the
time for the Trident project). It rolled most of the encryption behind
the scenes privately with Perl scripts to handle the encryption control
bits, so it was NOT the most elegant system in the world.
It did, however, fundamentally use gpg under the hood to handle message
encrypt/decrypt. It also made a keyring of all members' keys available
on its portal, though obviously that's a little harder to handle for
Mailman.
And what are you going to do about all those clear copies sitting in
recipient systems? If I were an attacker, I would assume that the
host of a "secret list" would be well-defended, but that's unlikely to
be true of all recipients.
> I'd also love if the mentors of the project would guide me on what
> to do next.
The first thing to do is to read the Google Contributor's Guide, then
ours. That lays out the basic process for applying, which includes
successfully contributing a merge request. (That request can be
trivial (fix a typo in a comment), the point is to be familiar with
our contribution process.)
Then get signed up for the mailing lists ([email protected]
[email protected]) and the #mailman channel on IRC where
historically realtime conversations have taken place.
One that's done, you can think about what your goals for the project
are. Encrypted lists are requested or suggested a lot, that's why we
have it listed as a task. However, none of the crypto people I follow
think they can be useful as a serious security tool, because the email
system is very complex and open at almost every point, while mailing
lists introduce further attack surface.
I would suggest starting with the most basic project, assuming away
the man-in-the-middle nature of Mailman itself and the problems of
forward secrecy, and just get the key distribution and reencryption
features implemented. You probably also want to deactivate all
features that allow users to subscribe themselves for encrypted lists
as well as the ability to change the status of a list from encrypted
to not so. Documentation of usage and limitations is going to be very
important. Do this throughout and make notes to yourself of usage
issues to remediate (have you used GPG recently?) and limitations
you'd like to remove if you have time.
I agree with this as well, start on focusing on the issue of key
distribution and reencryption features implemented.
> What I should read up on, etc. This project looks fun!
There seems to be a lot of work going on in the cryptography/privacy
community. I found this blog rather interesting, although it's only
peripherally connected to encrypted email (which it deprecates hard).
https://www.soatok.blog/2024/11/15/what-to-use-instead-of-pgp/
I'm actually in favor of suggesting that "encrypted email via mailing
lists" be a non-starter feature. On the basis that email is in itself
inherently insecure. I saw the 'encrypted lists' request and task a
while ago, and though I've implemented ways to do encrypted messaging in
Python with a combination of openssl, pgp, etc. depending on the
circumstances, the industry has typically considered email "inherently
insecure", unfortunately.
Most of the "secure mail" systems I'm also aware of use intermediate
tooling to share such 'secure emails' - either central portals shielded
by TLS and modern ciphers and all communication must be done via that
portal tooling, or through emails that are in fact stored in encrypted
PDF files and then to reply encrypted you have to use a TLS protected
"reply" button / portal that uses unique access links to handle replies
and then sends *those* replies to recipients via encrypted PDF files as
well.
However, the general idea of S/MIME or S/PGP-Inline has been more or
less frowned upon in quite a few environments because of the way email
provider systems are going. Microsoft Outlook, for example, has a
timeline to *deprecate* the traditional Outlook component and move to
"new Outlook" which is not extendable with PGP encryption, etc. and has
only very limited S/MIME support (using more of a 'webapp' than an
actual full email client). Thunderbird still supports both, but it's
easier for Open Source world to do that (and Thunderbird rolls their own
equivalent PGP compatibility to make it work on all systems).
The various 'options' stated by that blog post also don't all apply to
email, because some of them are simply "use other tools" or not well
implemented / globally available on all systems.
(Just keep this in mind if you pursue "encrypted lists" - the ITSec
industry understands how encrypted messages is a Good Thing, but that
there's no clear "front-runner" for handling it all out of all the
options available or supported by RFCs).
Thomas
_______________________________________________
Mailman-Developers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9
