Steven, Juergen, et al,
I had written most of this but interrupted, then Jurgen's email came in,
so... this got an edit! If a spot or two seems awkward it's because of
available time.
On Mon, 5 Feb 2024, Stephen J. Turnbull wrote:
Thanks for your followup. Although you suggested taking the
conversation private, I want to at least continue for one more post
because it's not clear to me that there's demand for this service that
is enough to justify the likely substantial cost of development. I
don't know how to implement poster-to-subscriber encryption
It's very straight-forward:
Public Key Encryption is used: Subscribers who want encrypted email
include their public key in their subscription details, just as they
include their name and digest type choices. The list itself, for its
reception, uses TLS. The outbound, from list server to subscriber is where
"the magic happens," encrypting the outbound to each user using their own
public key.
And then Juergen, as if on cue, added:
on Tue, 6 Feb 2024, Juergen Dollinger wrote:
We tried encrypted lists some years ago. Have a look at
http://non-gnu.uvt.nl/mailman-pgp-smime/
The idea is that there is a key for the list, the server decrypts the
E-mails and encrypts it for the recipients who have supplied a key.
Worked fine with that old version of Mailman 20 years ago.
But even in our quite nerdy environment only about the half of the
subscribers submitted a key for the list. (excuses are like 'I want to
use grep(1) for fulltext search in my list E-mails') So after the next
mailman update we dropped the patch and run unencrypted again.
I was unaware of this and I would have latched on with both hands!
Note that 20 years ago people, on whole, were less aware of the issues
with unencrypted emails and that HALF DID sign up is rather amazing. Most
users 20 years ago had "grown up with" a very friendly internet and
remembered those times without perceiving the risks, while the newcomers
were clueless to pretty much everything. Therefore the aprox. 50% number
is amazing.
HOWEVER, just becasue ONE email list of a group who realized it was there
had that experience says NOT A THING about how many who didn't know would
love to have a list where users HAD to use encryption to be on the list!
Consider that the safest email is one in which sender and recipient are on
the same system, MANY corporate environs would likely LOVE to have the
added flexibility and security that could come from having an email list
with this capability used for communications with not just employees but
their vendors.
It's myopic to see just one's own use case and think it applies across the
board.
Moving on, Steve goes on to say:
on the one
hand, and on the other hand most list owners are unable or unwilling
to manage their own hosts, and therefore have to provide the ability
to decrypt list traffic to a third party.
Over my long and storied 47 year career in computer science I've long
noted that the vast majority of users:
1) Don't know what they really want;
2) Don't have a clue what's easy and what's hard, and;
3) Don't hang out on email lists like this one.
(BTW the vast majority of project managers fit this same profile and
explains why we get such atrociously bad software sometimes, even from
gifted teams; if management is ignorant, it leads to less-than-optimal
results, especially with autocratic leadership that doesn't trust their
teams or want their creativity or input. But I digress...)
Steve:
But I could be quite wrong, and it's the members of the Mailman
community who are most likely to provide a critical mass of users to
say "that's just what I've always wanted, and here are the features I
want". If that critical mass doesn't show up, then I want to use my
time (and resources such as summer interns) on features that our
community *does* want.
The fact that nobody but you has raised their hand to say "I want
this" or "my list owners would really like this" is not a point in its
favor.
Your argument isn't any better.
The a majority of users have no clue that their emails are vulnerable in
transit on the internet, much less as a separate risk from their email
provider. So if it's your idea that we don't offer people the chance for
better and only focus on giving people what they already know they want,
progress is ... "suboptimal."
However, let me say to anybody who has read this far that although I
have played and continue to play the devil's advocate against
"privacy-preserving mailing lists", I want everybody to understand
that I am very much in favor of privacy.
Good.
But there are substantial technical hurdles to extreme requirements such
as "end-to-end encryption" of list traffic.
That is abjectly false, Juergen proved it, and not only was it NOT
difficult 20 years ago, in the 20 years since then what's fairly easily
possible has expanded considerably.
BTW, that one of us doesn't know how such things are done, by the way,
doesn't mean it's difficult. I love Will Roger's comment about such
things: "Everybody's ignorant, just about different things is all!"
It's no strike against anyone they don't know how things might be
accomplished, but something we all need to watch out for is our own false
presumption that if we don't see how something can be done it must be
hard.
The BIG question here is surely beyond this list's purview: Can we manage
to get an easy-to-use mechanism where any given user's public key can be
found? We now have at least The Electronic Frontier Foundation,
LetsEncrypt, and Proton AG who might well lend some muscle in this
venture: Think of a DNS-like system, perhaps even an actual evolution of
DNS itself, that permits users to declare their public keys in a publicly
findable way. For sites that want to keep user lists private but still do
this, perhaps a validation server could be devized with site-specific
policies on who gets to know what about a given username@domain entry -
think "I want to send encrypted email to user@your.system," and the mail
server or some similar server looks at the request and honors it by
sending the public key or not.
I posit that such a change would cause an explosion of use of encryption
for the simple reason that it's use can then be largely automated and thus
remove a huge fraction of the burden from the individual. It would
enable FAR more security, writ-large, than is under discussion here. I
won't bother you with all of it but just point your brain in pondering the
power of a very simple back-and-forth, "I use your key to send you
something encrypted, you send it back encrypted with my key telling me
what it is and we just validated each other."
IF a list manger like mailman wanted to handle this it surely could! In
that instance the broader key management via DNS or DNS-like system is not
necessary.
As for users wanting to grep emails, that's a lame excuse: Just leave the
email unencrypted in your local folder! That one's born of lazyness not
capability. However, using encryption today CAN BE an annoying thing. My
goal is to remove the time consuming hassle.
Richard / Steve dialogue:
> [M]y only real interest here is on the accessibility (privacy)
> aspect, and list-management software like mailman DOES have
> something to say about architectural details of implementation for
> an encrypted email world.
[...]
> A straight-forward approach might be, for example, that the entire set of
> data transferred between two MTAs is encrypted save the destination
> system's network address and the destination port.
I believe we already have that in some profiles of IPSec.
I've never seen / noticed that. A pointer would be nice!
> The MTA decrypts
Then the MTA is an agent-in-the-middle, and an obvious point of attack.
Yawn. Let people decide what their comfort level of risk is. The idea is
to ENABLE.
> All of this and much more is not particularly difficult to
> accomplish from a technical point of view - it's only a "Small
> Matter Of Code" as Michael Stonebraker (Turing Award Winner)
> famously says.
As I pointed out above, a lot of it is already implemented -- but not
in MTAs/MDAs, MUAs, or mailing lists. All of which have multiple
implementations and those implementations must agree exactly, or
somebody is going to get hacked.
I never said this was only a mailing list issue. We, collectively, need a
better infrastructure.
As I've said several times before in this kind of conversation, what
we need to do is identify specific privacy threats (mechanisms for
infringement) and user populations who need protection from them, and
then see if we can design a list (and probably MTA) architecture that
provides that protection.
The privacy threat: Unencrypted email in transit on the internet.
Affected user population: All email users.
And yes, MTA is the correct level, though as noted above, an email list
CAN help a lot WITHOUT an MTA level "fix".
Regards,
Richard
------------------------------------------------------
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/
Member address: arch...@jab.org
