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
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 wh
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
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 certain
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
On 06/29/2013 12:49 AM, Stephen J. Turnbull wrote: > Daniel Kahn Gillmor writes: > > 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". > > So you're suggesting that the *only* policies that should be > automatically implementable via certified key are > > (0) let this guy upload this key (and implicitly create a User if > needed), but he can't do *anything* else (not even subscribe) > until the list owner explicitly adds authorizations, > > (0.5) this guy gets the intersection of sets of privileges I ever want > to grant to anybody, and > > (1) this guy is co-owner of this list 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" 1) each "identity certifier" is itself an OpenPGP primary key fingerprint (or, the primary key itself). 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). 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. getting fancier, subscription and unsubscription messages, preference-changing messages, etc, could need to be signed by a valid, certified key as well. 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. In this model, the only special policy that is conferred upon an OpenPGP keyholder by the list administrator is "is this key one of the list's trusted identity certifiers or not?" > > i can see how this would be useful, but it means that there is more > > fiddly tracking of the validity state of each (key,userid) pairing > > that needs to be done to make this possible. > > I agree it's fiddly, I agree it's not in scope for Abhilash's GSoC > project, but for Mark's[1] sake I think we need to notify users whose > status changes from valid to invalid of the reason for the change. I hear you :) > > I suspect that the most common change from valid to not-valid will > > be an expired key or an expired certification (e.g. if the list > > owner's certification of the key expires). for the latter case, i > > can imagine that the certifier (the list admin) might want to be > > notified as well. > > 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, since that is the default interpretation of other pre-existing OpenPGP clients that will be seeing these same certifications. i hope this helps clarify my perspective -- i think i'm pushing for something simpler, not more complex; i think simplicity is one of the critical factors in making this stuff comprehensible to regular e-mail list administrators. Another (as you mention above) is clear, concise, and clean reporting about what is going on! --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
Daniel Kahn Gillmor writes: > ok, of course you have priority here, but i don't think we're actually > disagreeing :) Good! > The "simple, generic mechanism" you describe *is* key > manangement as far as i'm concerned, and i think it's an excellent > step. OK. I remember the context as being one of actually implementing (automated) policy decisions. That's where I really don't want him to go until the more limited GSoC project is done. > 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". So you're suggesting that the *only* policies that should be automatically implementable via certified key are (0) let this guy upload this key (and implicitly create a User if needed), but he can't do *anything* else (not even subscribe) until the list owner explicitly adds authorizations, (0.5) this guy gets the intersection of sets of privileges I ever want to grant to anybody, and (1) this guy is co-owner of this list ? > i can see how this would be useful, but it means that there is more > fiddly tracking of the validity state of each (key,userid) pairing > that needs to be done to make this possible. I agree it's fiddly, I agree it's not in scope for Abhilash's GSoC project, but for Mark's[1] sake I think we need to notify users whose status changes from valid to invalid of the reason for the change. > I suspect that the most common change from valid to not-valid will > be an expired key or an expired certification (e.g. if the list > owner's certification of the key expires). for the latter case, i > can imagine that the certifier (the list admin) might want to be > notified as well. 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. Footnotes: [1] He's the guy who does the most work on fielding problem reports from users. ___ 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 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 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 r
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
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
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
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
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 The 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
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 The 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 Jun 16, 2013, at 03: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. 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. 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). It's not great, but I still like the separation of concerns and the general concept that rules don't modify the message. To do otherwise introduces ordering dependency on the rules, which I really want to avoid. Ordering dependency on handlers can't be helped I think. I'm certainly open to ideas here, especially if this becomes more prevalent. -Barry signature.asc 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
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
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. > > > * 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
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
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
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
