Sron Dev writes:

Please let me know which platform you'd like me to elaborate on,

Me personally? None. I don't have time for theoretical discussions. Maybe somebody else does, you're welcome to pick a platform and hold forth (but see below for venue, this is almost certainly not the right list for that).

If you, or anyone else, has a specific feature request, or requirement for "ensur[ing] a safe environment for email discussions", I'd be happy to discuss what we can do about that. That discussion should move to mailman-developers@python.org or mailman-users@mailman3.org depending on whether the RFE is fairly clear (-developers) or if it needs refining by input from other users (-users), as new features are not going to be added to Mailman 2 (the subject of this list).

Steve

On 1/29/24 09:39, richard@karmannghia.org wrote:

Steve, Sron, et al:

Regarding:

"ensur[ing] a safe environment for email discussions"

...I would hope that all netizens are fully aware (and obviously not all are) that there is not and cannot be such a thing as "safe environment for email discussions" ...

Given what a sentence like "ensur[ing] a safe environment for email discussions" means in the current US political climate, when I see something like that, I killfile the sender.

IJS, Dima

richard@karmannghia.org writes:

...I would hope that all netizens are fully aware (and obviously not all are) that there is not and cannot be such a thing as "safe environment for email discussions" with email as now practiced and to create it requires a serious overhaul of the way email is conducted.

My original point was I feel perfectly safe here on Mailman lists (of course I am in a position to get people banned, so I am in fact safer than the average bear, though I would not mess with a Kodiak).

It doesn't have to be this way: email bodies and even the destination username and other parts of email headers COULD be encrypted when enroute via the same mechanisms as we have long used for secured web sites,

True, and in fact many sites implement the enroute part, it's called mandatory TLS. I would imagine the proposals to make traffic analysis more difficult would apply here too.

and even end-to-end encryption isn't too difficult to implement, and I'd lay a substantial bet that an open-sourced effort harnessing the ideas of DKIM / SPF / DMARC could easily and simply accomplish this.

I've thought a lot about this, it has been proposed multiple times as a GSoC project for Mailman, and this is simply not true for mailing lists as implemented in Mailman. In particular, it's simply not possible to achieve end-to-end encryption as a mailing list function. The list has to have access to the session key to give access to that key to subscribers, at which point you've been hacker-in-the-middle-d. I can imagine applications where you're willing to trust the list, though, and if there were demand for that, I'd be willing to supervise a GSoC student who wanted to implement it.

Note that it is certainly possible to have end-to-end encryption of list email, but it requires that each poster have all the subscriber keys. I guess you could marry a keyserver with a mailing list, and if you want to call that "end-to-end encryption via mailing list" go ahead, but you still have to solve the problem of getting posters to keep their keyrings up to date, so I consider that "not a mailing list function".

And of course you only asked for security of "data in motion", but then you've got the harder problem of securing data at rest (which also requires cooperation from either recipients or from their MUAs -- buwhahahahaha!)

However, the simple (and for me painful) truth is that The Powers That Be _obviously_ do not want us to have secure communications. Their excuse is fear ("terrorism!") and their more dominant motive is profit. It's truly as simple is that.

It's not that simple though. While you're gonna need some *serious* booking up before you can win that substantial bet ;-), it would be possible (and has been done, cypherpunkery is real!) The problem is that we don't want it as bad as the cypherpunks did. So far we've been able to resist laws that require backdoors (who knows how many backdoors are there by bribery or other skullduggery, but it's not *legal*). So for some things we can win. But if we want really secure mail, as secure as for financial networks (which aren't perfect but they do OK), we're going to have to pay for it, and the average bloke isn't interested. They'd rather be outraged when their secrets get blabbed and their brother-in-law who actually did the dirty deed says "wasn't me, was some 400-lb-hacker-in-Mom's-basement".

Anyone who thinks their unencrypted emails are in any way secure on the open internet is, unfortunately SADLY mistaken.

This is true. Security by obscurity works up to a point, but if you ever get targeted by the FBI you're toast.

P.S. PERHAPS someone reading this has the energy and gumption to change this?! I sure hope so! ...I've been using email for 47 years now, I did my part, I tried hard, it's up to younger generations to carry it forward now. But I'll be happy to assist anyone else's efforts on this!

I'm not volunteering for the hacking part, but if somebody eligible for GSoC wants to propose it, and the mentors like the proposal, I'll mentor it.

Steve

On Tue, 30 Jan 2024, Dmitri Maziuk wrote:

On 1/30/24 07:47, Stephen J. Turnbull wrote:

...

richard@karmannghia.org writes: ...

...

Anyone who thinks their unencrypted emails are in any way secure on the open internet is, unfortunately SADLY mistaken.

This is true. Security by obscurity works up to a point, but if you ever get targeted by the FBI you're toast.

Whereas anyone who thinks their encrypted-in-transit e-mails are in any way secure on gmail servers, is delusional. Google gives FBI access to mailboxes, and they won't ever tell you because gag orders (google it).

Dima

You're obviously correct, Dima; who your mail host is matters, and who your recipent(s) mail hosts are also matter and if either is like Google, Hotmail, Yahoo, etc, well... it's pretty pointless.

People need to remember: If it's free, YOU are the product!

But more than that, I try and get people to understand that due to their ignorant choice of gmail, for example, I won't send them all kinds of emails I might otherwise send, even though it's not encrypted end-to-end because (as someone pointed out) obscurity works to a point, so SOME things I might not mind sending in that way.

I have a good handful of friends who I have managed to convince to move to Proton Mail because I just won't deal with them via email if they remain on gmail, etc.

Richard

Hi Richard,

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 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.

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.

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. But there are substantial technical hurdles to extreme requirements such as "end-to-end encryption" of list traffic. On the positive side, reduced- expectation implementations with encryption on the wire both directions and in queue files, for example, which would pretty much eliminate attacks on data-in-motion and somewhat reduce the attack surface for data-at-rest (eg, in queues on disk on the list host and possibly even in archives) might be useful in some applications. I would be happy to discuss such applications, and the cost of implementing them in Mailman (ie, how much writing and rewriting of code).

richard@karmannghia.org writes:

[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. But that has nothing to do with mailing lists, and I'm not real interested in going into MTA implementation.

The MTA decrypts

Then the MTA is an agent-in-the-middle, and an obvious point of attack.

It's entirely reasonable to design the architecture so the list management code has optional access to the body of an email,

Now the list manager is an agent-in-the-middle and a point of attack, too. Both are very likely unacceptable in the case of a large-scale hosting service, without a massive effort to design and implement a key management system that can restrict access to keys to authorized uses. Absent such a system, the operator of a mailing list would also need to be a system administrator with security qualifications to match perceived threats.

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.

From the point of view of a mailing list, if the list itself is functional then there's no issue with traffic analysis insofar as legitimate analysis of list traffic is concerned.

I'm not sure what you mean by "traffic analysis". I am suggesting that membership in some encrypted lists will be considered privacy- relevant, and therefore mail being delivered from what is likely a single-purpose host to a mailbox infringes privacy of the mailbox's owner. Consider for example a list for victims of stalking or domestic violence. Knowledge that a target is subscribed to such a list could trigger violence on the part of the abuser.

One would imagine that in a properly architected system designed to encrypt various email headers, the design would account for email-list-pertinent options.

In the mailing list context, the fundamental question of "properly architected" is "who has which keys and how do they get them?" Mandatory TLS solves the problem automatically for a single TCP connection. This can be generalized to automatic secure key exchange for all members of a (sufficiently small) synchronous group chat in the chat software. I don't see how it can be generalized to a mailing list which is fundamentally asynchronous, should deal with recipients whose MTAs almost certainly don't participate in such key exchange protocols (other than TLS), and potentially of much larger scale.

...

...

and even end-to-end encryption isn't too difficult to implement,

...

I've thought a lot about this, it has been proposed multiple times as a GSoC project for Mailman, and this is simply not true for mailing lists as implemented in Mailman.

...

From here, your analysis goes ... weird. I suppose one of us misunderstood the other: What's needed is something like "mandatory TLS" but even better since that doesn't, so far as I know, differentiate between headers and the email body, much less parts of the header such as the subject line. But it's the scope that's the weird part; this needs to be done at the MTA level, not at the mailing list manager level. At least that's my view

How do you propose to make that work, even for the simplest case of just encrypting the whole SMTP DATA element? The MTA doesn't know who the ultimate recipients are. Mandatory TLS can secure privacy-on-the- wire by using a secure key exchange protocol such as Diffie-Hellman because all you need to know is "the recipient is on the other end of this connection". But the mailing list stands between the MTA and the recipient.

It's also far simpler to solve this at the MTA level. But then maybe I misunderstood you.

I don't think you have thought through what the mail flows are, and at what points messages need to be decrypted and accessible to which software (and therefore potentially to human agents such as host administrators).

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.

Steve

Juergen Dollinger writes:

We tried encrypted lists some years ago. Have a look at http://non-gnu.uvt.nl/mailman-pgp-smime/

Thank you for describing your experience! The people side is always hard. I'm not unhopeful though, but it's going to take work, especially good design.

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.

That's exactly how I would do it, except you wouldn't receive posts until you submitted a key. Having half the copies vulnerable on-the-wire and on-disk would not fill me with warm fuzzy feelings. :-)

I think this could be fairly useful in environments where people are paranoid enough to leave the mail encrypted on disk. But even the DV case that I mentioned -- would it stay encrypted for long if a few of the abusers discovered its existence? It would only take one!

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')

Today I don't think that excuse would fly, machines are fast enough that few email bodies would take noticable time to decrypt, and languages like Python and Perl provide very high quality email processing libraries. p-grep-p would be written real fast, and it would work fast too.

Steve

richard@karmannghia.org writes:

It's very straight-forward:

C'mon, man, Grandpa knows how to tie his shoes. The construction of such an encrypted list not technically terribly complex---as you said yourself, a SMOC. The problems are describing *who* is the adversary, *what* will they do to invade your privacy, and *how* does the proposed system thwart those threats. You are completely ignoring those questions. And no, "unencrypted mail is a threat" to "everybody" isn't a serious attempt to address them, given that almost everyone is using MTAs that support TLS nowadays.

Subscribers who want encrypted email include their public key in their subscription details,

What about the needs of *posters*, who are *at least* as important as subscribers here, who want to keep *their* posts private? That's why "encryption-optional" lists make no sense to me, except as a proof of concept. And the prescription to greppers to leave their mail folders unencrypted is not comforting to the authors, either.

I see vanishly small added security in an encryption-optional mailing list of the kind Juergen described. As a proof-of-concept, it was a brave experiment that maybe could have led to something. But it didn't.

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! [...] It's myopic to see just one's own use case and think it applies across the board.

Round 'em up, man. I listen to the community. I'm listening to you.

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.

So? I think they *do* know a very large fraction of what they want at the level of expressing *requirements* (WIBNI ...). Dealing with what's easy and what's hard is our problem as developers, not theirs. With that knowledge, we can help them refine and prioritize their requirements, and sometimes discover new ones. Convincing them that we understand their requirements and know easy vs. hard is also our problem. And the lack of like-thinking users on mailing lists like this one is a problem for advocates (like you?)

...

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.

Your definition of "end-to-end" is not the one in common use. A system where an intermediate node decrypts, then reencrypts and forwards, is not "end-to-end encrypted" in any usage I've seen before,

It's really not useful to discuss technical issues if you won't at least use the accepted definitions of such critical terms. You're welcome to argue that given the threats you perceive, it's not an important requirement for an encrypted mailing list. But given the ease which which systems are penetrated these days, I disagree for most purposes I can think of.

Steve

Christian Buser via Mailman-Users writes:

Please don’t feed the trolls...

I don't have time to visit trolly websites, either.

Lucky me, this time! :) :) :)