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). rich...@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 ------------------------------------------------------ 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
