Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
On Jul 02, 2013, at 01:04 PM, Stephen J. Turnbull wrote: No, in Mailman 3 it is not, and cannot be, internal to OpenPGP because addresses are *not* Users. There is a many-to-one (address-to-User) mapping (I hope; if it's many-to-many, we can probably dodge that bullet by allowing sets of Users in many places we'd normally expect a User). You're correct, although technically addresses don't have to be associated with users. But if they are, they can only be associated with a single user. Users can control multiple addresses. While unlinked addresses are supported by the model, I don't think there's any case where unlinked addresses are really exposed in any meaningful way that a user or admin can utilize. So I think if we can associate OpenPGP user ids to email addresses, that will almost always imply an association to a user. However, binding an email address to a User is a Mailman operation, and at the point of adding an email to a User, in the scenario I'm thinking of the only thing Mailman has to go on is the association of a key to an email. If this is the initial email for that User, there's no problem. But for additional emails, there *is* a problem. The identification of existing emails with the email to be added is not necessarily guaranteed by the key presented. We need to think carefully about how this works (or can be subverted). Very definitely. While it's easy to associate an address with an existing user, it's not entirely clear how we can do that in a secure way. -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
On 07/01/2013 01:58 AM, Stephen J. Turnbull wrote: 2) subscribers to an OpenPGP-enabled mailman mailing list subscribe, unsubscribe, receive, and send mails as usual (though messages not signed with valid keys will not be re-sent to the list). Not necessarily. It may be necessary to sign admin messages as well (subscribe, unsubscribe, set vacation) Your phrasing presumes that the only role of Users (the internal representation of an identity) is to act as a subscriber who reads and posts. The way I think of it is that Users may have several roles (read, post, moderate, admin) for each list. Each of these roles may be certified by a different agent of the owner, where agents are represented by different keys. It sounds to me like you're trying to use OpenPGP keys for authorization here, rather than for authentication. I think that's a mistake. OpenPGP's so-called web of trust is a network of identity certifications; it does not typically include authorization information. This is limited scope is actually a feature, for (at least) three reasons: 0) OpenPGP certifications are typically public -- you do not always want to publish your authorization decisions. 1) because OpenPGP certifications are statements about identity, you can perform some reasoned inference about them (e.g. following reasonable chains of authenticated certifications) that would be much harder to do if the semantics of any given certification could potentially indicate authorization as well as authentication. 2) because the certifications are just statements about identity, they are easier for most users to make; this is because it is simpler to consider identity on its own than to consider both identity and authorization bundled together. More certifications means a richer pool to draw from when trying to calculate authentication. Known subscriber doesn't really make sense in the Mailman 3 world. There are Users, they can be members of a list (ie, known to the list) and they can have roles (reader, poster, etc). It's not clear to me that requiring posters to have the reader role in this world is the right way to determine membership. i'm just suggesting that those roles are authorization statements about users and lists. I apologize for not knowing the official mailman terminology here, so if you can help me translate, i would be very grateful :) I think those authorization statements should *stay the same* in mailman lists that use OpenPGP as they are in mailman lists that do not use OpenPGP. so when you say certified key above, i think you're talking about what is known as a valid key -- that is, the relevant user ID is bound to its primary key by a certification made by one of my trusted identity certifiers. That seems to be nonsense, though. Key-to-UID binding is done by the user database; it's only meaningful inside of Mailman. The key-to-uid binding is done by the OpenPGP keyring. this is the entire point of an OpenPGP keyring: given a signed message and a from address, can you confirm that this message really came from the stated from address? A signature on a key is not a way of making an authenticated link to a UID in Mailman, AFAICS. It's only a of certifying that the signer knows the keyholder and that this is that keyholder's key, and that the signer trusts the keyholder not to allow others to use her key. That doesn't mean (in the absence of actually binding a UID to the key *in* the certification) that this keyholder corresponds to any given UID. I don't think i understand what you're saying. when Alice makes an OpenPGP certification on Bob's key (Alice signs Bob's key), she is explicitly binding Bob's User ID to his public key. So saying in the absence of actually binding a UID to the key in the certification doesn't make sense to me. I also don't see why, in a web-of-trust model, you would want to use that definition of valid. (If the key is determined to be none of corrupt, expired, or revoked, I would call that valid.) A key not signed by a trusted certification key would be (completely) untrusted, but you can imagine various degrees of trust. For example, in a member recommendation model, you might allow any member's key to certify the reader role but not the poster (or vice-versa for a list handling privacy issues!) Having validity depend on trust makes the concept of validity quite ambiguous. It's not surprising that these terms still confuse people; they were muddled even in the GPG documentation up until a few years ago. It's worth clarifying them explicitly: * A literal key (nothing but a key, no UIDs, no self-sigs, etc -- not an OpenPGP certificate) that is well-formed is syntactically valid. * a syntactically-valid key whose certifications we are willing to rely on when evaluating other keys and user IDs is a trusted key. This is the same thing as saying that the key has full ownertrust. * a (key,userID)
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Daniel Kahn Gillmor writes: On 07/01/2013 01:58 AM, Stephen J. Turnbull wrote: The way I think of it is that Users may have several roles (read, post, moderate, admin) for each list. Each of these roles may be certified by a different agent of the owner, where agents are represented by different keys. It sounds to me like you're trying to use OpenPGP keys for authorization here, rather than for authentication. I think that's a mistake. A certification is a statement that *I* know *this* key to be associated with *that* person, and only that person. Depending on the value of I, you may extend different levels of trust to that person. You're already down the rabbit hole, my dear Alice. The question is whether to eat the red mushroom. ;-) OpenPGP's so-called web of trust is a network of identity certifications; it does not typically include authorization information. There's no authorization information in the web of trust. The authorization decision is made on the basis of being presented a signed key; that's all Mailman has to go on. Depending on the identity of the signer *Mailman* may grant additional authorizations. Consider the example I gave of subscription by member recommendation. This is limited scope is actually a feature, for (at least) three reasons: 0) OpenPGP certifications are typically public If you don't want to expose different roles as OpenPGP identities, don't. Nevertheless, the capability is available in OpenPGP: the identity-to-key mapping is not one-to-one. 1) because OpenPGP certifications are statements about identity, you can perform some reasoned inference about them The whole point of the suggestion is based on this fact. There's no authorization in the signatures. Mailman makes decisions about the authorization to grant based on the identity(s) of the signer(s). 2) because the certifications are just statements about identity, they are easier for most users to make; Sure, but some users are smarter than the average bear, or have requirements beyond those of a typical panda. Known subscriber doesn't really make sense in the Mailman 3 world. There are Users, they can be members of a list (ie, known to the list) and they can have roles (reader, poster, etc). It's not clear to me that requiring posters to have the reader role in this world is the right way to determine membership. i'm just suggesting that those roles are authorization statements about users and lists. They are. We're just confused about user. I mean Mailman User, you mean PGP userID. They're not equivalent, at least not at the stage of adding a key to a User in Mailman. so when you say certified key above, i think you're talking about what is known as a valid key -- that is, the relevant user ID is bound to its primary key by a certification made by one of my trusted identity certifiers. That seems to be nonsense, though. Key-to-UID binding is done by the user database; it's only meaningful inside of Mailman. The key-to-uid binding is done by the OpenPGP keyring. this is the entire point of an OpenPGP keyring: given a signed message and a from address, can you confirm that this message really came from the stated from address? No, in Mailman 3 it is not, and cannot be, internal to OpenPGP because addresses are *not* Users. There is a many-to-one (address-to-User) mapping (I hope; if it's many-to-many, we can probably dodge that bullet by allowing sets of Users in many places we'd normally expect a User). However, binding an email address to a User is a Mailman operation, and at the point of adding an email to a User, in the scenario I'm thinking of the only thing Mailman has to go on is the association of a key to an email. If this is the initial email for that User, there's no problem. But for additional emails, there *is* a problem. The identification of existing emails with the email to be added is not necessarily guaranteed by the key presented. We need to think carefully about how this works (or can be subverted). I don't think i understand what you're saying. when Alice makes an OpenPGP certification on Bob's key (Alice signs Bob's key), she is explicitly binding Bob's User ID to his public key. So saying in the absence of actually binding a UID to the key in the certification doesn't make sense to me. Mailman UID != GPG UID, at least not at present, and probably not for the foreseeable future. It's not surprising that these terms still confuse people; they were muddled even in the GPG documentation up until a few years ago. It's worth clarifying them explicitly: * A literal key (nothing but a key, no UIDs, no self-sigs, etc -- not an OpenPGP certificate) that is well-formed is syntactically valid. * a syntactically-valid key whose certifications we are willing to rely on when evaluating other keys and user IDs is a trusted
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Daniel Kahn Gillmor writes: Maybe we're not talking about the same thing. OpenPGP certification should be identity certification, and nothing else. trying to extend OpenPGP certification to mean something other than identity certification sounds like a bad idea to me -- it breaks all kinds of other assumptions within the OpenPGP world. I was thinking that the baseline is: 0) each e-mail list has a set of identity certifiers Yes. 1) each identity certifier is itself an OpenPGP primary key fingerprint (or, the primary key itself). Yes. Probably the primary key. 2) subscribers to an OpenPGP-enabled mailman mailing list subscribe, unsubscribe, receive, and send mails as usual (though messages not signed with valid keys will not be re-sent to the list). Not necessarily. It may be necessary to sign admin messages as well (subscribe, unsubscribe, set vacation) Your phrasing presumes that the only role of Users (the internal representation of an identity) is to act as a subscriber who reads and posts. The way I think of it is that Users may have several roles (read, post, moderate, admin) for each list. Each of these roles may be certified by a different agent of the owner, where agents are represented by different keys. 3) if a signed message comes in, the server checks to make sure that the message is signed properly with a key that is certified (by one of the list's identity certifiers) to belong to the person in the message's From: header, *and* that person is a known subscriber to the list. Known subscriber doesn't really make sense in the Mailman 3 world. There are Users, they can be members of a list (ie, known to the list) and they can have roles (reader, poster, etc). It's not clear to me that requiring posters to have the reader role in this world is the right way to determine membership. so when you say certified key above, i think you're talking about what is known as a valid key -- that is, the relevant user ID is bound to its primary key by a certification made by one of my trusted identity certifiers. That seems to be nonsense, though. Key-to-UID binding is done by the user database; it's only meaningful inside of Mailman. A signature on a key is not a way of making an authenticated link to a UID in Mailman, AFAICS. It's only a of certifying that the signer knows the keyholder and that this is that keyholder's key, and that the signer trusts the keyholder not to allow others to use her key. That doesn't mean (in the absence of actually binding a UID to the key *in* the certification) that this keyholder corresponds to any given UID. So this interpretation is useful only if a new UID is being assigned to that key in this transaction. It doesn't work if we are binding a new key to an existing UID. I also don't see why, in a web-of-trust model, you would want to use that definition of valid. (If the key is determined to be none of corrupt, expired, or revoked, I would call that valid.) A key not signed by a trusted certification key would be (completely) untrusted, but you can imagine various degrees of trust. For example, in a member recommendation model, you might allow any member's key to certify the reader role but not the poster (or vice-versa for a list handling privacy issues!) Having validity depend on trust makes the concept of validity quite ambiguous. I would interpret a certification expiry differently: as the period of time for which permission to register the key is valid. If we want an expiry for User authentication, probably a generic tool for managing that in Mailman itself would be sufficient for this purpose and useful elsewhere. certification expiry means i am willing to claim that this key belongs to this person for N months; if it's later than N months, and you don't see a newer certification from me, please don't rely on my claim any more. I think it would be a mistake to interpret that any other way, I don't interpret it any other way. I'm assuming that once the key is registered, Mailman and the list owner take responsibility for trusting keys, and they no longer rely on the certification at all. If the list owner wants to use the certification in authenticating the User, that would be OK. But then the temptation to use an infinite expiry would be strong (unless a mechanism is provided to make re-signing convenient -- but not *too* convenient: sorry, no re-sign all button will be provided!). With infinite expiry certification is meaningless in the long run (in the long run we're all dead, and a signed message from someone known to be dead should be a clue...). since that is the default interpretation of other pre-existing OpenPGP clients that will be seeing these same certifications. Why are they delegating so much power to the certifications? That seems very strange to me. I certainly wouldn't stop trusting a key that had been used to sign messages
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
All great questions. Let me just add this. On Jun 28, 2013, at 01:03 PM, Stephen J. Turnbull wrote: There does need to be a way for list owners to take complete control of key management, and there does need to be convenience in management. I think that the key signed by list-owner's list-key-management-key is an important step for convenience. I suspect that the hook needed to implement it would be able to support various policies (probably through the 'chain of rules' mechanism implemented in Mailman 3 core -- might require some refactoring of core I guess). I like this latter proposal, and it should be pretty straightforward to implement. This means, of course, that the list-owner's key needs to be known to the mailman instance. could there be more than one list-owner's key? Yes. As implied above, I envision there being a specific key used to sign for permission to do X FVO X such as subscribe, post, get member list, sign other people's keys (Web of Trust!), etc, so there could be several keys in that sense. For paranoid folks who regularly expire their keys, I would expect that keys might overlap in time, so there probably should be a list of keys for each function. In some cases one key will fit all, of course: I only sign for people I trust to do everything a signature gives authorization to do. Another complication is that keys will probably be attached to users, but users have relationships with list across the entire Mailman installation. So if it were list owners that were responsible for key management, how does that cross list boundaries? What about lists on the same system but in different domains? Does the site admin have to delegate key management responsibilities to list owners? I can imagine some kind of attack involving a list owner who approves a member's key for one list, and then using that to attack other lists on the same system. Tricky business. -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
On 06/28/2013 12:03 AM, Stephen J. Turnbull wrote: Daniel Kahn Gillmor writes: I think Abhilash's question above is a really important question, It is. and one that really should be addressed by this GSoC project. Vetoed (I'm the mentor). Abhilash is welcome to work on key management if he wants to, but he will not be evaluated on it (subject to satisying the need discussed below for a simple, generic mechanism to allow the list owner to conveniently authorize keys without uploading them himself), and he will be warned if it appears that mission creep is endangering the mission. ok, of course you have priority here, but i don't think we're actually disagreeing :) The simple, generic mechanism you describe *is* key manangement as far as i'm concerned, and i think it's an excellent step. I wouldn't want the list to do much more than this, actually; we don't want to encourage the list admin to do a lot of fiddly, error-prone, list-specific work; normal public OpenPGP certifications should be able to cover that. You're welcome to continue to lobby him to work on key management though (in public, please :-). :) Yes. As implied above, I envision there being a specific key used to sign for permission to do X FVO X such as subscribe, post, get member list, sign other people's keys (Web of Trust!), etc, so there could be several keys in that sense. For paranoid folks who regularly expire their keys, I would expect that keys might overlap in time, so there probably should be a list of keys for each function. In some cases one key will fit all, of course: I only sign for people I trust to do everything a signature gives authorization to do. I think this is too fine-grained, actually -- OpenPGP certifications should attest to people's identities; those identities should have permissions in mailman the same way that non-cryptographically-verifiable identities have permissions in mailman. The semantics are simple and graspable if we say for list X, rely on OpenPGP certifications from the following keys to prove cryptographic identity. A) if refreshing keys from the keyserver network is something we want mailman to do, when should it happen? how often? Good questions, both the implicit one (do we want?) and the explict ones. Beyond my technical knowledge at the moment, though. As someone who has worked on this sort of key management in other contexts (e.g. monkeysphere), the simplest mechanism is a scheduled cronjob update from the keyservers. One step up (fancier) is to couple the cronjob (which is still necessary to check for revocations) with a key expiry script, that knows when the next key or certification will expire and check from the keyservers at that point in time. If the cronjob is frequent enough, i don't think the fancier approach has a great cost/benefit analysis, so i would just start with the cronjob. Consider also that a cronjob that just does gpg --refresh should be sufficient to pull in revocations and modifications to expiration dates, but it won't pull in new keys that might be valid. I think that's fine for starters, and the new keys can be handled by: B) if mailman can't find a valid key+userid for a known subscriber, when should it query the public keyservers to try to find one? Immediately, subject to the caveat that this would possibly be a separate queue. Oh, I suppose you mean should Mailman automatically add a key that the user may not really have intended to use? That's an extremely complex question. If signed by list owner is the only criterion and it's necessary and sufficient, I'd go with always. Otherwise you have a complex policy, and I'd have to see the policy to know when querying is appropriate. I also think always is a reasonable default policy, though some list managers may want to be able to set it to never if they don't want arbitrary messages sent to the list to be able to force the list software to interact with the public keyservers directly. C) how should mailman accept uploads of key material that *don't* go through the keyservers? Please expand. A signed key is a signed key, or isn't it? ok, there are two approaches i can see: 0) no key upload happens manually; all keys and OpenPGP certifications are fetched from the public keyservers. If a user's key isn't in the public keyservers, or the certification by the list admin hasn't been uploaded to the public keyservers are ignored. 1) in addition to the use of the public keyservers, direct key upload is allowed -- e.g. people can e-mail OpenPGP certificates to a special address, or can upload them to a web form. In this case, a user who doesn't want their key on the public keyservers (or an admin who doesn't want to distribute their certifications to the public keyservers) can participate; also, a mailman installation which is (for whatever reason) unable to access any of the public keyservers can still access
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
On 06/28/2013 10:11 AM, Barry Warsaw wrote: Another complication is that keys will probably be attached to users, but users have relationships with list across the entire Mailman installation. So if it were list owners that were responsible for key management, how does that cross list boundaries? What about lists on the same system but in different domains? Does the site admin have to delegate key management responsibilities to list owners? I can imagine some kind of attack involving a list owner who approves a member's key for one list, and then using that to attack other lists on the same system. Tricky business. An OpenPGP certification of a key+userid just means that the certifier believes that the key belongs to the person who has that user ID (including the e-mail address). i think the best way to implement stephen's suggestion is that in order to be able to post to a signed-message-only list, a list member must have a key that has been certified by the list's administrator. Note that this does *not* mean that a non-list-member whose key has been certified by the list's administrator can post. List membership and key certification are orthogonal attributes; Both should be needed (plus a valid signature on the message, of course!) before a message is passed on to such a list. --dkg signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
On Sat 2013-06-15 12:48:34 -0400, Stephen J. Turnbull wrote: Abhilash Raj writes: * How to ensure the keys belong the email it says it does? This is not in scope for your project. Key upload is for bootstrapping strong authentication, therefore you should assume there is no strong authentication to authenticate the key upload. Man-in- the-middle attacks on the key upload mechanism are *way* above your pay grade. I think Abhilash's question above is a really important question, and one that really should be addressed by this GSoC project. I'm not claiming that the implementation needs to be perfect, but i do think mailman should support something more sophisticated than oh, anyone can just upload a new key via the webinterface. * How are we actually using the web-of-trust model of OpenPGP? We aren't. Simplistic rules like two signatures are not going to be good enough for anybody who cares. Writing a framework so that admins can configure the signature policy is also above your pay grade. You should consider providing hooks for such validation, and maybe a proof of concept implementation to hook into it. Something like a key is considered valid if it is signed by the list-owner. I like this latter proposal, and it should be pretty straightforward to implement. This means, of course, that the list-owner's key needs to be known to the mailman instance. could there be more than one list-owner's key? If someone wants to propose a more sophisticated key verification step later, that could be an extension. The above proposal makes the following things possible: 0) mailman can fetch keys directly from the OpenPGP keyserver network if they haven't been uploaded directly, and still retain a reliable cryptographic chain (since any fetched keys that are not signed by the list-owner should be ignored). 1) mailman can refresh keys automatically from the OpenPGP keyserver network, or accept arbitrary uploades of updated keys, also without worrying about non-cryptorgraphic compromise. This means that people can update their key's expiration dates, and they can publish key revocation to the public keyserver network without needing to worry about fiddling with their subscription on every mailing list directly. These are great! It does raise a few logistical questions: A) if refreshing keys from the keyserver network is something we want mailman to do, when should it happen? how often? B) if mailman can't find a valid key+userid for a known subscriber, when should it query the public keyservers to try to find one? C) how should mailman accept uploads of key material that *don't* go through the keyservers? D) if mailman notices that a subscriber's key has expired or been revoked or somehow become invalid in some other way, is it expected to notify that subscriber of the change in status? if so, how? (i recommend that the answer is no notification, at least in this initial implementation. Thanks for weighing these options! --dkg pgpCLn0gzOaTy.pgp Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Daniel Kahn Gillmor writes: I think Abhilash's question above is a really important question, It is. and one that really should be addressed by this GSoC project. Vetoed (I'm the mentor). Abhilash is welcome to work on key management if he wants to, but he will not be evaluated on it (subject to satisying the need discussed below for a simple, generic mechanism to allow the list owner to conveniently authorize keys without uploading them himself), and he will be warned if it appears that mission creep is endangering the mission. He is also welcome to use any free time he finds to work on encrypted lists, and there's been mention of a conceptually similar project on DMARC implementation (a message-signing technology for use by MTA owners rather than list owners and members) that he may want to work on. Which, if any, to do is up to Abhilash. You're welcome to continue to lobby him to work on key management though (in public, please :-). But let's drop the discussion of a relation to GSoC, please. Abhilash has his contract, and key management policy is not in it. I'm not claiming that the implementation needs to be perfect, but i do think mailman should support something more sophisticated than oh, anyone can just upload a new key via the webinterface. Nobody is saying otherwise. I'm just saying that key management in general is not Abhilash's problem for GSoC. There does need to be a way for list owners to take complete control of key management, and there does need to be convenience in management. I think that the key signed by list-owner's list-key-management-key is an important step for convenience. I suspect that the hook needed to implement it would be able to support various policies (probably through the 'chain of rules' mechanism implemented in Mailman 3 core -- might require some refactoring of core I guess). I like this latter proposal, and it should be pretty straightforward to implement. This means, of course, that the list-owner's key needs to be known to the mailman instance. could there be more than one list-owner's key? Yes. As implied above, I envision there being a specific key used to sign for permission to do X FVO X such as subscribe, post, get member list, sign other people's keys (Web of Trust!), etc, so there could be several keys in that sense. For paranoid folks who regularly expire their keys, I would expect that keys might overlap in time, so there probably should be a list of keys for each function. In some cases one key will fit all, of course: I only sign for people I trust to do everything a signature gives authorization to do. A) if refreshing keys from the keyserver network is something we want mailman to do, when should it happen? how often? Good questions, both the implicit one (do we want?) and the explict ones. Beyond my technical knowledge at the moment, though. B) if mailman can't find a valid key+userid for a known subscriber, when should it query the public keyservers to try to find one? Immediately, subject to the caveat that this would possibly be a separate queue. Oh, I suppose you mean should Mailman automatically add a key that the user may not really have intended to use? That's an extremely complex question. If signed by list owner is the only criterion and it's necessary and sufficient, I'd go with always. Otherwise you have a complex policy, and I'd have to see the policy to know when querying is appropriate. C) how should mailman accept uploads of key material that *don't* go through the keyservers? Please expand. A signed key is a signed key, or isn't it? D) if mailman notices that a subscriber's key has expired or been revoked or somehow become invalid in some other way, is it expected to notify that subscriber of the change in status? if so, how? (i recommend that the answer is no notification, at least in this initial implementation. I would expect that noticing would happen during the process of authenticating a request. If key status *changes* (a key that was never valid for the list should cause silent denial of the request to reduce backscatter), then the user should be notified that key status has changed *and* how that was determined. Anything else is going to leave the list owner in the dock. Also, the key owner may wish to prosecute somebody for misuse of her key, and should be informed of the misuse. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Not in GSoC scope, this is direct to Barry (and anybody else, including GSoC students of course, interested in core). Barry Warsaw writes: I know this is a little backwards, but it's probably the best match for the current rule/chain model. I have a smallish problem with this model. Specifically, for a list with a maximum size, I think it's probably desirable to do any MIME part stripping *before* the size test. But this doesn't fit the chain(s) - pipeline model AFAICS. I suspect there are probably other such cases where a bit of preprocessing would be useful, in particular if we implement a reencryption facility as Abhilash originally proposed. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Hi, On Sun, Jun 16, 2013 at 01:48:34AM +0900, Stephen J. Turnbull wrote: Abhilash Raj writes: This is a list of topics that probably needs to be discussed in detail again. I tried to mention in breif about the discussions in past personally with a someone or on mm-dev list. Please ignore the topics which you feel has already reached a inference. It is a long mail though. * How to ensure the keys belong the email it says it does? This is not in scope for your project. Key upload is for bootstrapping strong authentication, therefore you should assume there is no strong authentication to authenticate the key upload. Man-in- the-middle attacks on the key upload mechanism are *way* above your pay grade. snip * How are we actually using the web-of-trust model of OpenPGP? We aren't. Simplistic rules like two signatures are not going to be good enough for anybody who cares. Writing a framework so that admins can configure the signature policy is also above your pay grade. You should consider providing hooks for such validation, and maybe a proof of concept implementation to hook into it. Something like a key is considered valid if it is signed by the list-owner. Indeed, that could work. Another way to deal with it could be: a key is considered valid if it is imported in the trusted keyring of the current list. And declare deciding wether to import out of the scope of the project. Bye, Joost -- Ich will in euch einen neuen Geist geben; Ich werde aus eurem Fleisch das Herz aus Stein nehmen, und will euch geben ein Herz aus Fleisch. --Ez 36,2 http://mdcc.cx/ ※ http://ad1810.com/ ※ Eindhoven, .nl ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Joost van Baal-Ilić writes: Indeed, that could work. Another way to deal with it could be: a key is considered valid if it is imported in the trusted keyring of the current list. And declare deciding wether to import out of the scope of the project. I think that we necessarily have to trust the list's keyring, that's what it's there for. The question is how do keys get into the trusted list. What I had in mind was that signed-by-list-owner would be a reason to import automatically. The model I have in mind is that signing Mr. A's key means the list owner is willing to vouch for authenticity of that key to others, meaning he know Mr. A (including where to find him if he cheats). This is probably good enough for lists where the 3-way handshake (subscribe, request confirmation, confirm) is good enough authentication of the mail address itself. On the other hand, it's still not a strong authentication in the sense Abhilash wants. Mr. A might have tricked the list owner into signing a throw-away key which will be used to spoof Mr. B's email address. A similar trick would defeat Barry's scheme of sending the one-time key in encrypted form, if the bad guy both submits the PGP key and can intercept Mr. A's mail. Both of these schemes have some merit in that there's a very short window of opportunity for the bad guy. Once an authentic key has been linked to an address, authentication is very strong. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
On 06/15/2013 02:45 PM, Barry Warsaw wrote: On Jun 15, 2013, at 11:12 AM, Abhilash Raj wrote: * Inline pgp should be supported or not? Probably not as a first step. PGP/MIME will be easier to support so do that first. As Stephen suggests, a survey of popular MUAs might be useful. My own (Claws Mail) supports them both, though I'm not sure which is default. I certainly use and prefer PGP/MIME. I think Thunderbird/EnigMail uses inline pgp by default, but PGP/MIME can be set as the default per account and is always available when composing a message. At one time EnigMail discouraged PGP/MIME as being supported by few MUAs, but that caveat appears to have been removed from the current UI. -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
On 06/15/2013 11:42 PM, Stephen J. Turnbull wrote: Barry Warsaw writes: I know this is a little backwards, but it's probably the best match for the current rule/chain model. I have a smallish problem with this model. Specifically, for a list with a maximum size, I think it's probably desirable to do any MIME part stripping *before* the size test. But this doesn't fit the chain(s) - pipeline model AFAICS. FYI, on my production server (MM 2.1 - well actually 2.2+ ;) I reorder the GLOBAL_PIPELINE to put MIMEDel before Hold for exactly this reason. -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Barry Warsaw writes: It's a valid complaint. What I've suggested in the past is that a rule can do some *nondestructive* processing of a message before it makes its decision. The rule would either throw out the results of the processing (possibly leading to duplication of work) or would cache the results, e.g. in the metadata dictionary (possibly leading to a rather large pickle/in-memory data). Yeah, I was afraid you'd say something like that. This could be quite expensive in terms of duplicating work for encryption, but I guess we cross that bridge when we come to it. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
Stephen's already given a very good response, so I'll just add a few more thoughts. On Jun 15, 2013, at 11:12 AM, Abhilash Raj wrote: * How to ensure the keys belong the email it says it does? One method proposed for this was to send a confirmation email to the email address, but what if the email is intercepted in between and the attacker confirms the sign up of the person he is trying to impersonate? Or this is a problem that can be solved with SSL and is not of our concern? One thing you could do is to send a confirmation message encrypted to that public key. You'd have to make sure that the confirmation token is *only* in the encrypted part (e.g. you could not include the token in the Subject header as we currently do for convenient just hit reply functionality). The point is that if Mailman has the public key, because they user just uploaded it, then the intended recipient must have the private key. If you encrypt the confirmation token to this public key, then the recipient's private key should be able to decrypt it. An evil interceptor wouldn't have that private key and thus would not be able to hijack anything. * Inline pgp should be supported or not? Probably not as a first step. PGP/MIME will be easier to support so do that first. As Stephen suggests, a survey of popular MUAs might be useful. My own (Claws Mail) supports them both, though I'm not sure which is default. I certainly use and prefer PGP/MIME. * Should mailman keep the signature of sender before signing or strip if off? You'll want to look at the IMailingList.anonymous_list flag. I think the function to prase message, check signature, resign message could be there in utilities as a gpg.py module. Which is where I think I should first start from. I was looking for a python wrapper for gnupg and found two options: [python-gnupg][2] and [gnupg-interface][3]. GnuPG-Interface was what was used in pgp-smime patch for mailman 2.1.5. I don't have much idea about waht should be used, will post on mailman-developers. Please use python-gnupg. I've been using it lately for a different project and I think it's very solid, with a nice API. Plus, it's actively maintained by a good developer who is responsive to bugs and feature requests. Plus, it's Python 3 compatible. :) I think it does make sense to put some primitives in a utilities/gpg.py module. The things that should go in here are probably higher level APIs that Mailman itself will find useful. Be sure that anything that goes in here has a unit test (at least) and possibly a doctest. About the outgoing messages i was thinking if we can create a signing queue and sign runner which simply signs each message with list's private-key and then the message moves on to outgoing queue where it can be delivered without any furthur changes. Any ideas about this? I'm with Stephen here, I don't think a separate queue is required. A new queue implies another runner, which means another process that must be managed. Signing isn't *that* much of a bottleneck that adding it will gum up the works too much. I think it would be okay to sign the message once for all recipients, even if we're doing personalization. The personalized parts will have to go in the unsigned bits though (e.g. the headers and any user-specific footer parts). If not, then the outgoing signatures will have to be added by the mta component so that it signs the final message before it's sent to the upstream MTA for delivery. -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
On Jun 16, 2013, at 01:48 AM, Stephen J. Turnbull wrote: * the message is queued in incoming queue * the incoming runner wakes up, finds the message and calls a few functions to verify the signature of the message(assuming the function already has public key of the user from somewhere) I think you need to study the architecture more carefully. I don't think it's appropriate for the incoming runner to be calling functions, rather there should be a Rule in the pipeline that does this checking. Right. Remember that all the incoming runner does[*] is take a message that's already been parsed, and send it through the posting chain. That's the process whereby the message and its metadata flow through rules to determine whether the post is allowed. Clearly, signature checking should occur in a rule. This will also make it easier for you to test. * If the message signature is found to be valid the message is then passed on to onther runners as usual (without stripping of the signature as per my assumption till now, need discussion on this) else it is dropped or bounced depending on the state of verification( like if the signature is older we can inform the sender as the delay may have been due to smtp deliver and simply drop the message if the signature is verified to be wrong). The outcome of the signature checking rule is a boolean result. There will be an action associated with that. Because of the way links and rules work, the action is only taken if the rule hits. This means that I think the rule should probably return True if the message is *unsigned* and the action in that case is to jump to one of the Hold, Reject, or Discard chains (depending on a configuration variable - but we can discuss this). If the rule misses (i.e. returns False) then it means the signature was valid and rule processing just continues on. I know this is a little backwards, but it's probably the best match for the current rule/chain model. Maybe. Again you should check current style. I Think what you propose is OK, as Rules and Handlers can live in the same file since they are distinguished by their signatures. But I forget exactly how Barry organizes this stuff. Currently there are separate directories for rules and handlers. For now, it's best to follow that model. -Barry [*] It also creates IAddress records for any email addresses it's never seen before, but that's besides the point under discussion. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
