Re: [Mailman-Developers] GSoC Project: pgp plugin
Hi Abhilash Raj, Hi Steve
Thank you both for taking the time and considering to mentor me.
On 28.02.2016 04:48, Abhilash Raj wrote:
If you don't know, I worked on this project some time back in GSoC 2013. The current state of that project is not very good and probably needs a *lot* of rebasing to do.
I did not know that. What were the problems?
On 28.02.2016 04:48, Abhilash Raj wrote:
Here is a link1 to discussions that have already been done before on this
I think that link is missing, I'm very interested in looking into this.
First of all, if this wasn't clear, my plan was to make a re-encryption gateway. Messages are encrypted to the listservers keypair and re-encrypted there for each of the recipients. How did your implementation work, Abhilash Raj?
I had two modes of Operation in mind: (a) One that doesn't encrypt all of the mail but gives users the option to send and recieve pgp encrypted mails. This might be useful for very small private lists where some communication is protected against eavesdropping in other ways, when a list is in the progress of introducing encrypted communication or for (other) testing purposes. (b) A strict mode that keeps all the communication encrypted and won't ever send out mail without encrypting it.
- Optionally forced encryption (such a list never sends mail to an adress to which it can't encrypt with a pubkey that has a certain level of trust and/or won't accept inbound mail in plaintext) is in fact essential for the application to make sense. By Optionally, I meant that it should be possible to not force encryption which would be
The strict (b) mode should certainly be default, and the (a) mode of operation.
On 28.02.2016 04:48, Abhilash Raj wrote:
I have a few small questions doubts about your features below...
Some features could be:
- Automatic pubkey collection from inbound mail
What happens if I send a forged email with some user's email address as FROM and use a fake key? Automatic public key collection isn't a very good idea, you should be *very* careful about how you handle public keys.
The idea was to collect the public keys so an authority (list admin) could manually set their trust levels which would be necessary in strict (b) mode in order to use a key at all.
On 28.02.2016 04:48, Abhilash Raj wrote:
- Outbound mail encryption and signature validation
I would suggest you keep encryption as a part of extended goals in case of GSoC. You'd be surprised how many students are not able to finish their proposal in time.
I will try to make a realistic evaluation of what's possible in my GSoC before i apply.
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
- Outbound mail encryption and signature validation
- Inbound mail decryption and outbound mail signature
I don't understand these pairs. Why encrypt mail *to* the server if it's only going to be decrypted on the way out? Why encrypt outgoing posts if they might have been read in the clear before being received?
On 28.02.2016 04:48, Abhilash Raj wrote:
Shouldn't both be working differently? Encrypted emails distributed as encrypted email and signed email distributed as signed.
I paired them this way because outbound encryption and inbound signature validation requires the application to manage the subscribers public keys and inbound encryption requires the application to manage the lists keypair so I would probably implement 1. and 2. as well as 3. and 4. at the same time. 1-4 are part of the core functionality. My list is badly structured.
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
End-to-end encryption or signature or both seems to be the right thing.
The concept of a mailserver doesn't allow real end-to-end encryption if each recipient uses a different keypair. A user would have to have the public keys of all the subscribers at the time of sending a mail to the list and encrypt the mail for each of them. This would require modification to the client software for this to behave like a mailinglist, especially if subscribers join or leave the list.
A method for real end-to-end mailinglists is described in Practical Encrypted Mailing Lists by Neal H. Walfield, feb 2016 1 but this is not what I want to do. Another alternative would be to have a pgp proxy outside the list server that does the re-encryption but this would not be as convenient as having a re-encrypting listserver.
Considering that all subscribers recieve the mail and usually listserver admins are subscribers theirselves, I think than an implementation where the listserver recieves a copy as well definitly has some uses. Users would have to be aware that the privacy of communication relies on the protection of the listserver and listserver admins would have to be aware that they need to protect the lists keypair.
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
Out of scope for one summer IMHO. It's not obvious what the security implications are. Better to do key generation off-line.
What security implications are you refering to? Some servers have true hardware rngs. If there isn't enough entropy, no keys should generate with /dev/random as entropy source. Having the proper crypto libraries and random number sources is in the responsibility of the user. With this concept, there will be a private key on the listserver and this should be clear to the users. It has security implications but I think they are admissible.
- A mailinterface for organizing the encrypted lists, subscribers public keys and trust levels
- A webinterface
These too are out of scope. Again, security implications are unclear.
- PGP Information in the messages (e.g. was the incoming mail signed by a trusted subscriber?)
What does "trusted" mean? Trusted means that the key has been marked as trusted by an authority (list admin). The authority has to decide what actions have to be taken to mark a key as trusted. This could be exchanging fingerprints in real
On 28.02.2016 10:30, Stephen J. Turnbull wrote: life or fingerprints could be confirmed by a trusted third party (eg a list member that already knows that public key).
- A mailinterface for organizing the encrypted lists, subscribers public keys and trust levels
I would like to know more on how you plan to do this. It could be one command to list all the pubkey fingerprints along with
On 28.02.2016 04:48, Abhilash Raj wrote: the corresponding subscriber email adress, the trust level and another command to set the trust level of a pubkey (by its fingerprint). This would require the list admin to securely identify, for example by pgp signing command mails.
I did not yet research how to implement mail commands.
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
Yes, crypto support (both encryption and signatures) are a FAQ. However, nobody has ever really provided specific requirements (ie, the threat model to defend against), so it's very hard to decide what to do, and documentation of whatever is done would be impossible.
I'm not exactly sure what a threat model is. But a scenario this would protect from is eavesdropping on list communication by a mailserver – or anyone in case inter-mailserver communication or access to a mailbox isn't properly secured. A scenario where privacy could still be violated is when an eavesdropper gains access to the mailserver or any subscribers private key.
I don't understand, why would documentation be impossible?
Jonas
On 02/29/2016 03:02 AM, Jonas wrote:
Hi Abhilash Raj, Hi Steve
Thank you both for taking the time and considering to mentor me.
On 28.02.2016 04:48, Abhilash Raj wrote:
If you don't know, I worked on this project some time back in GSoC 2013. The current state of that project is not very good and probably needs a *lot* of rebasing to do.
I did not know that. What were the problems?
I did implement the signature verification for the application/pgp-signed emails and was able to get everything working too. There was some plumbing left that I never went back to finish.
On 28.02.2016 04:48, Abhilash Raj wrote:
Here is a link1 to discussions that have already been done before on this
I think that link is missing, I'm very interested in looking into this.
Sorry about that, here it is http://www.mail-archive.com/mailman-developers%40python.org/msg13413.html.
First of all, if this wasn't clear, my plan was to make a re-encryption gateway. Messages are encrypted to the listservers keypair and re-encrypted there for each of the recipients. How did your implementation work, Abhilash Raj?
Kinda similar, just that I mostly focused on just implementing the key management and verifying digital signatures and figuring out a message structure that would let us retain signatures from both list and original sender.
I had two modes of Operation in mind: (a) One that doesn't encrypt all of the mail but gives users the option to send and recieve pgp encrypted mails. This might be useful for very small private lists where some communication is protected against eavesdropping in other ways, when a list is in the progress of introducing encrypted communication or for (other) testing purposes. (b) A strict mode that keeps all the communication encrypted and won't ever send out mail without encrypting it.
- Optionally forced encryption (such a list never sends mail to an adress to which it can't encrypt with a pubkey that has a certain level of trust and/or won't accept inbound mail in plaintext) is in fact essential for the application to make sense. By Optionally, I meant that it should be possible to not force encryption which would be
The strict (b) mode should certainly be default, and the (a) mode of operation.
On 28.02.2016 04:48, Abhilash Raj wrote:
I have a few small questions doubts about your features below...
Some features could be:
- Automatic pubkey collection from inbound mail
What happens if I send a forged email with some user's email address as FROM and use a fake key? Automatic public key collection isn't a very good idea, you should be *very* careful about how you handle public keys.
The idea was to collect the public keys so an authority (list admin) could manually set their trust levels which would be necessary in strict (b) mode in order to use a key at all.
On 28.02.2016 04:48, Abhilash Raj wrote:
- Outbound mail encryption and signature validation
I would suggest you keep encryption as a part of extended goals in case of GSoC. You'd be surprised how many students are not able to finish their proposal in time.
I will try to make a realistic evaluation of what's possible in my GSoC before i apply.
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
- Outbound mail encryption and signature validation
- Inbound mail decryption and outbound mail signature
I don't understand these pairs. Why encrypt mail *to* the server if it's only going to be decrypted on the way out? Why encrypt outgoing posts if they might have been read in the clear before being received?
On 28.02.2016 04:48, Abhilash Raj wrote:
Shouldn't both be working differently? Encrypted emails distributed as encrypted email and signed email distributed as signed.
I paired them this way because outbound encryption and inbound signature validation requires the application to manage the subscribers public keys and inbound encryption requires the application to manage the lists keypair so I would probably implement 1. and 2. as well as 3. and 4. at the same time. 1-4 are part of the core functionality. My list is badly structured.
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
End-to-end encryption or signature or both seems to be the right thing.
The concept of a mailserver doesn't allow real end-to-end encryption if each recipient uses a different keypair. A user would have to have the public keys of all the subscribers at the time of sending a mail to the list and encrypt the mail for each of them. This would require modification to the client software for this to behave like a mailinglist, especially if subscribers join or leave the list.
A method for real end-to-end mailinglists is described in Practical Encrypted Mailing Lists by Neal H. Walfield, feb 2016 1 but this is not what I want to do. Another alternative would be to have a pgp proxy outside the list server that does the re-encryption but this would not be as convenient as having a re-encrypting listserver.
Considering that all subscribers recieve the mail and usually listserver admins are subscribers theirselves, I think than an implementation where the listserver recieves a copy as well definitly has some uses. Users would have to be aware that the privacy of communication relies on the protection of the listserver and listserver admins would have to be aware that they need to protect the lists keypair.
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
Out of scope for one summer IMHO. It's not obvious what the security implications are. Better to do key generation off-line.
What security implications are you refering to? Some servers have true hardware rngs. If there isn't enough entropy, no keys should generate with /dev/random as entropy source. Having the proper crypto libraries and random number sources is in the responsibility of the user. With this concept, there will be a private key on the listserver and this should be clear to the users. It has security implications but I think they are admissible.
- A mailinterface for organizing the encrypted lists, subscribers public keys and trust levels
- A webinterface
These too are out of scope. Again, security implications are unclear.
- PGP Information in the messages (e.g. was the incoming mail signed by a trusted subscriber?)
What does "trusted" mean? Trusted means that the key has been marked as trusted by an authority (list admin). The authority has to decide what actions have to be taken to mark a key as trusted. This could be exchanging fingerprints in real
On 28.02.2016 10:30, Stephen J. Turnbull wrote: life or fingerprints could be confirmed by a trusted third party (eg a list member that already knows that public key).
- A mailinterface for organizing the encrypted lists, subscribers public keys and trust levels
I would like to know more on how you plan to do this. It could be one command to list all the pubkey fingerprints along with
On 28.02.2016 04:48, Abhilash Raj wrote: the corresponding subscriber email adress, the trust level and another command to set the trust level of a pubkey (by its fingerprint). This would require the list admin to securely identify, for example by pgp signing command mails.
I did not yet research how to implement mail commands.
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
Yes, crypto support (both encryption and signatures) are a FAQ. However, nobody has ever really provided specific requirements (ie, the threat model to defend against), so it's very hard to decide what to do, and documentation of whatever is done would be impossible.
I'm not exactly sure what a threat model is. But a scenario this would protect from is eavesdropping on list communication by a mailserver – or anyone in case inter-mailserver communication or access to a mailbox isn't properly secured. A scenario where privacy could still be violated is when an eavesdropper gains access to the mailserver or any subscribers private key.
I don't understand, why would documentation be impossible?
Jonas
Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40g...
Security Policy: http://wiki.list.org/x/QIA9
-- thanks, Abhilash Raj
Jonas writes:
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
End-to-end encryption or signature or both seems to be the right thing.
The concept of a mailserver doesn't allow real end-to-end encryption if each recipient uses a different keypair.
It's true that keeping things secret from the server would be hard, but at least in theory it would be possible to avoid decryption in normal operation by having the originator use a "session key" and a symmetric algorithm to do the actual encryption, and then using the user's PGP key to encrypt the session key. Then all you need to do is decrypt the session key and reencrypt it with the user's (or users') key(s).
If possible (I mean I suspect it requires privacy software that doesn't currently exist) this would be nice because you don't have to worry about having copies of decrypted text in memory, in swap, and in temporary files.[1] Of course this would mean that such an MLM could not decorate the mail with header or footer, but you probably should not do that anyway because of limitations of MUAs and users in displaying/interpreting indications of what portions of a message are secure.
Considering that all subscribers recieve the mail and usually listserver admins are subscribers theirselves,
In security, you either need to take care of the unusual case, or document that the case is not covered. Wouldn't you rather have a short list of "you can't use my software in these cases: ..."?
I think than an implementation where the listserver recieves a copy as well definitly has some uses.
Copy of the encrypted message, maybe, although I would argue that archiving should default to off for an encrypted list. But decrypted, I disagree strongly, and would do my best to block integration of such a feature (it's Barry's call in the end, not mine). If you really want the server to have a decrypted copy, that is easily enough accomplished by subscribing a decryption program to the list. Our goal should be to do our best to reduce the additional attack surface presented by the MLM by default, and leave the users to their own devices in reducing security and increasing risk.
Users would have to be aware that the privacy of communication relies on the protection of the listserver and listserver admins would have to be aware that they need to protect the lists keypair.
If there's anything we know about users, it's that they only learn about security when they experience harm from lack of it, and even then few actually do anything effective about it.[2] Admins have enough to worry about without drawing an arrow labeled "attack here" on their system (running an encrypted list already paints a bullseye on it). Whenever possible, we want random clueless behavior to *not* result in a security hole. So yes, the private keys must be protected. But as much as possible we should try to ensure that if the list server is compromised, the communications are not.
[Automated key generation is out] of scope for one summer IMHO. It's not obvious what the security implications are. Better to do key generation off-line.
What security implications are you refering to? Some servers have true hardware rngs. If there isn't enough entropy, no keys should generate with /dev/random as entropy source. Having the proper crypto libraries and random number sources is in the responsibility of the user.
I'm not talking about the availability of these basic facilities. If the system doesn't have them, none of the necessary crypto facilities will be available from Python anyway. I'm talking about the introduction of unnecessary complexity. I don't know offhand how to attack it. I'm saying that before we introduce additional complexity we need to be pretty sure that it's hard to attack.
If you want to do this, you need to learn the security mindset[3]. Otherwise, you're very likely going to leave behind bugs that someday will bite somebody who is earnestly trying to do the right thing.
Back in the day, I set the config on Smail 3.1.0.99 to block outside- to-outside relays, as recommended by the documentation. I was shocked to be informed a few weeks later that my box was being used as an open relay. Guess what? They documented that feature, but the implementation was a stub until 3.1.0.101.
With this concept, there will be a private key on the listserver and this should be clear to the users. It has security implications but I think they are admissible.
Of course there has to be a private key usable by the list server because the whole purpose of the exercise is to avoid distribution of all keys to all subscribers. But stealing the keys is only one of the many ways to get past a lock. We need to protect the hinges on the other side of the door, too. The most effective way to do that is to ensure they're not exposed in the first place.
What does "trusted" mean?
Trusted means that the key has been marked as trusted by an authority (list admin).
OK.
I'm not exactly sure what a threat model is.
Find out! It's more than just a few random scenarios, I'll tell you that much.
But a scenario this would protect from is eavesdropping on list communication by a mailserver
How about one run by a subscriber?
– or anyone in case inter-mailserver communication or access to a mailbox isn't properly secured.
You can assume that SMTP is unlikely to be secured. TLS is more common nowadays but hardly universal.
What makes you think that users won't save decrypted messages? You need to document that as a threat and exclude it from those you can protect against.
I don't understand, why would documentation be impossible?
Users have a habit of assuming that "secure" (or whatever favorable adjective is involved) applies to their use case. You need to be able to describe the threats that are and are not defended against in detail and very clearly.
For example, one use case that has been brought up in the past is a mailing list that contains private conversations among a group of patients and the group therapist. But you can expect that in the case of a multi-therapist clinic, they will want to share a single server with a professional administrator. That server's admin presumably has access to the list keys, but you don't want that in this use case, not even if she is one of the therapists.
Thus, you need to make it clear that this scenario (a server admin who should not have access to the privileged conversations) is *not* included in *your* threat model. Server admins are necessarily trusted, and excluded as sources of security breaches. If you don't clearly specify that threat model in your design, you're not going to be able to document it well enough for users to understand.
Footnotes: [1] Think "the disk was stolen". Private keys on that disk? Not necessarily. What? That wasn't part of your threat model? Better say so!
[2] Consider how many people continue to use Windows!
[3] https://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html
Thank you Stephen.
I agree with your points and I will make sure to clearly document any potential security pitfalls of the system for the users and to write a detailed and precise design plan that has special emphasis on security implications before I start coding this project.
However, at the moment I'm in the middle of writing my Project Proposal. May I send you a draft along with personal questions? And/Or Abhilash Raj, may I send you those?
To make a first impression, I thought about writing a general blog post on the state of mailinglist/group communication encryption that covers the efforts toward encrypted lists in mailman. Could that work as a first impression instead of fixing a bug in mailman? The easier ones seem to get patched faster than I can catch up.
Thank you again, Jonas
On 29.02.2016 21:49, Stephen J. Turnbull wrote:
Jonas writes:
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
End-to-end encryption or signature or both seems to be the right thing.
The concept of a mailserver doesn't allow real end-to-end encryption if each recipient uses a different keypair.
It's true that keeping things secret from the server would be hard, but at least in theory it would be possible to avoid decryption in normal operation by having the originator use a "session key" and a symmetric algorithm to do the actual encryption, and then using the user's PGP key to encrypt the session key. Then all you need to do is decrypt the session key and reencrypt it with the user's (or users') key(s).
If possible (I mean I suspect it requires privacy software that doesn't currently exist) this would be nice because you don't have to worry about having copies of decrypted text in memory, in swap, and in temporary files.[1] Of course this would mean that such an MLM could not decorate the mail with header or footer, but you probably should not do that anyway because of limitations of MUAs and users in displaying/interpreting indications of what portions of a message are secure.
Considering that all subscribers recieve the mail and usually listserver admins are subscribers theirselves,
In security, you either need to take care of the unusual case, or document that the case is not covered. Wouldn't you rather have a short list of "you can't use my software in these cases: ..."?
I think than an implementation where the listserver recieves a copy as well definitly has some uses.
Copy of the encrypted message, maybe, although I would argue that archiving should default to off for an encrypted list. But decrypted, I disagree strongly, and would do my best to block integration of such a feature (it's Barry's call in the end, not mine). If you really want the server to have a decrypted copy, that is easily enough accomplished by subscribing a decryption program to the list. Our goal should be to do our best to reduce the additional attack surface presented by the MLM by default, and leave the users to their own devices in reducing security and increasing risk.
Users would have to be aware that the privacy of communication relies on the protection of the listserver and listserver admins would have to be aware that they need to protect the lists keypair.
If there's anything we know about users, it's that they only learn about security when they experience harm from lack of it, and even then few actually do anything effective about it.[2] Admins have enough to worry about without drawing an arrow labeled "attack here" on their system (running an encrypted list already paints a bullseye on it). Whenever possible, we want random clueless behavior to *not* result in a security hole. So yes, the private keys must be protected. But as much as possible we should try to ensure that if the list server is compromised, the communications are not.
[Automated key generation is out] of scope for one summer IMHO. It's not obvious what the security implications are. Better to do key generation off-line.
What security implications are you refering to? Some servers have true hardware rngs. If there isn't enough entropy, no keys should generate with /dev/random as entropy source. Having the proper crypto libraries and random number sources is in the responsibility of the user.
I'm not talking about the availability of these basic facilities. If the system doesn't have them, none of the necessary crypto facilities will be available from Python anyway. I'm talking about the introduction of unnecessary complexity. I don't know offhand how to attack it. I'm saying that before we introduce additional complexity we need to be pretty sure that it's hard to attack.
If you want to do this, you need to learn the security mindset[3]. Otherwise, you're very likely going to leave behind bugs that someday will bite somebody who is earnestly trying to do the right thing.
Back in the day, I set the config on Smail 3.1.0.99 to block outside- to-outside relays, as recommended by the documentation. I was shocked to be informed a few weeks later that my box was being used as an open relay. Guess what? They documented that feature, but the implementation was a stub until 3.1.0.101.
With this concept, there will be a private key on the listserver and this should be clear to the users. It has security implications but I think they are admissible.
Of course there has to be a private key usable by the list server because the whole purpose of the exercise is to avoid distribution of all keys to all subscribers. But stealing the keys is only one of the many ways to get past a lock. We need to protect the hinges on the other side of the door, too. The most effective way to do that is to ensure they're not exposed in the first place.
What does "trusted" mean?
Trusted means that the key has been marked as trusted by an authority (list admin).
OK.
I'm not exactly sure what a threat model is.
Find out! It's more than just a few random scenarios, I'll tell you that much.
But a scenario this would protect from is eavesdropping on list communication by a mailserver
How about one run by a subscriber?
– or anyone in case inter-mailserver communication or access to a mailbox isn't properly secured.
You can assume that SMTP is unlikely to be secured. TLS is more common nowadays but hardly universal.
What makes you think that users won't save decrypted messages? You need to document that as a threat and exclude it from those you can protect against.
I don't understand, why would documentation be impossible?
Users have a habit of assuming that "secure" (or whatever favorable adjective is involved) applies to their use case. You need to be able to describe the threats that are and are not defended against in detail and very clearly.
For example, one use case that has been brought up in the past is a mailing list that contains private conversations among a group of patients and the group therapist. But you can expect that in the case of a multi-therapist clinic, they will want to share a single server with a professional administrator. That server's admin presumably has access to the list keys, but you don't want that in this use case, not even if she is one of the therapists.
Thus, you need to make it clear that this scenario (a server admin who should not have access to the privileged conversations) is *not* included in *your* threat model. Server admins are necessarily trusted, and excluded as sources of security breaches. If you don't clearly specify that threat model in your design, you're not going to be able to document it well enough for users to understand.
Footnotes: [1] Think "the disk was stolen". Private keys on that disk? Not necessarily. What? That wasn't part of your threat model? Better say so!
[2] Consider how many people continue to use Windows!
[3] https://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html
Hi Jonas,
On 03/18/2016 10:29 AM, Jonas wrote:
Thank you Stephen.
I agree with your points and I will make sure to clearly document any potential security pitfalls of the system for the users and to write a detailed and precise design plan that has special emphasis on security implications before I start coding this project.
Great!
However, at the moment I'm in the middle of writing my Project Proposal. May I send you a draft along with personal questions? And/Or Abhilash Raj, may I send you those?
I guess you can upload drafts of proposal (in google docs) on GSoC's website and we all mentors can have a look at it/comment on it if needed.
To make a first impression, I thought about writing a general blog post on the state of mailinglist/group communication encryption that covers the efforts toward encrypted lists in mailman. Could that work as a first impression instead of fixing a bug in mailman? The easier ones seem to get patched faster than I can catch up.
We need you to fix one easy bug so as to judge your capability to actually implement the proposal that you are proposing. Although, we have mandated one patch towards your application, a small documentation patch and some of your previous patches to different projects (preferably, but not required, in Python) could work. Does that sound good? I can point you to several places we need more documentation ;-)
Thank you again, Jonas
On 29.02.2016 21:49, Stephen J. Turnbull wrote:
Jonas writes:
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
End-to-end encryption or signature or both seems to be the right thing.
The concept of a mailserver doesn't allow real end-to-end encryption if each recipient uses a different keypair.
It's true that keeping things secret from the server would be hard, but at least in theory it would be possible to avoid decryption in normal operation by having the originator use a "session key" and a symmetric algorithm to do the actual encryption, and then using the user's PGP key to encrypt the session key. Then all you need to do is decrypt the session key and reencrypt it with the user's (or users') key(s).
If possible (I mean I suspect it requires privacy software that doesn't currently exist) this would be nice because you don't have to worry about having copies of decrypted text in memory, in swap, and in temporary files.[1] Of course this would mean that such an MLM could not decorate the mail with header or footer, but you probably should not do that anyway because of limitations of MUAs and users in displaying/interpreting indications of what portions of a message are secure.
Considering that all subscribers recieve the mail and usually listserver admins are subscribers theirselves,
In security, you either need to take care of the unusual case, or document that the case is not covered. Wouldn't you rather have a short list of "you can't use my software in these cases: ..."?
I think than an implementation where the listserver recieves a copy as well definitly has some uses.
Copy of the encrypted message, maybe, although I would argue that archiving should default to off for an encrypted list. But decrypted, I disagree strongly, and would do my best to block integration of such a feature (it's Barry's call in the end, not mine). If you really want the server to have a decrypted copy, that is easily enough accomplished by subscribing a decryption program to the list. Our goal should be to do our best to reduce the additional attack surface presented by the MLM by default, and leave the users to their own devices in reducing security and increasing risk.
Users would have to be aware that the privacy of communication relies on the protection of the listserver and listserver admins would have to be aware that they need to protect the lists keypair.
If there's anything we know about users, it's that they only learn about security when they experience harm from lack of it, and even then few actually do anything effective about it.[2] Admins have enough to worry about without drawing an arrow labeled "attack here" on their system (running an encrypted list already paints a bullseye on it). Whenever possible, we want random clueless behavior to *not* result in a security hole. So yes, the private keys must be protected. But as much as possible we should try to ensure that if the list server is compromised, the communications are not.
[Automated key generation is out] of scope for one summer IMHO. It's not obvious what the security implications are. Better to do key generation off-line.
What security implications are you refering to? Some servers have true hardware rngs. If there isn't enough entropy, no keys should generate with /dev/random as entropy source. Having the proper crypto libraries and random number sources is in the responsibility of the user.
I'm not talking about the availability of these basic facilities. If the system doesn't have them, none of the necessary crypto facilities will be available from Python anyway. I'm talking about the introduction of unnecessary complexity. I don't know offhand how to attack it. I'm saying that before we introduce additional complexity we need to be pretty sure that it's hard to attack.
If you want to do this, you need to learn the security mindset[3]. Otherwise, you're very likely going to leave behind bugs that someday will bite somebody who is earnestly trying to do the right thing.
Back in the day, I set the config on Smail 3.1.0.99 to block outside- to-outside relays, as recommended by the documentation. I was shocked to be informed a few weeks later that my box was being used as an open relay. Guess what? They documented that feature, but the implementation was a stub until 3.1.0.101.
With this concept, there will be a private key on the listserver and this should be clear to the users. It has security implications but I think they are admissible.
Of course there has to be a private key usable by the list server because the whole purpose of the exercise is to avoid distribution of all keys to all subscribers. But stealing the keys is only one of the many ways to get past a lock. We need to protect the hinges on the other side of the door, too. The most effective way to do that is to ensure they're not exposed in the first place.
What does "trusted" mean?
Trusted means that the key has been marked as trusted by an authority (list admin).
OK.
I'm not exactly sure what a threat model is.
Find out! It's more than just a few random scenarios, I'll tell you that much.
But a scenario this would protect from is eavesdropping on list communication by a mailserver
How about one run by a subscriber?
– or anyone in case inter-mailserver communication or access to a mailbox isn't properly secured.
You can assume that SMTP is unlikely to be secured. TLS is more common nowadays but hardly universal.
What makes you think that users won't save decrypted messages? You need to document that as a threat and exclude it from those you can protect against.
I don't understand, why would documentation be impossible?
Users have a habit of assuming that "secure" (or whatever favorable adjective is involved) applies to their use case. You need to be able to describe the threats that are and are not defended against in detail and very clearly.
For example, one use case that has been brought up in the past is a mailing list that contains private conversations among a group of patients and the group therapist. But you can expect that in the case of a multi-therapist clinic, they will want to share a single server with a professional administrator. That server's admin presumably has access to the list keys, but you don't want that in this use case, not even if she is one of the therapists.
Thus, you need to make it clear that this scenario (a server admin who should not have access to the privileged conversations) is *not* included in *your* threat model. Server admins are necessarily trusted, and excluded as sources of security breaches. If you don't clearly specify that threat model in your design, you're not going to be able to document it well enough for users to understand.
Footnotes: [1] Think "the disk was stolen". Private keys on that disk? Not necessarily. What? That wasn't part of your threat model? Better say so!
[2] Consider how many people continue to use Windows!
[3] https://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html
Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40g...
Security Policy: http://wiki.list.org/x/QIA9
-- thanks, Abhilash Raj
Abhilash Raj writes:
Thanks for picking this up, Abhilash!
Jonas writes:
However, at the moment I'm in the middle of writing my Project Proposal. May I send you a draft along with personal questions?
If you mean do I like cats, I don't see what that has to do with GSoC. ;-) If you mean specific to your proposal, no, it doesn't work that way. Mentors aren't tutors, and your proposal isn't to one or more potential mentors, it's to the project. The project decides what proposals to accept, subject to mentor availability. The project decides whether your design is appropriate, whether your code is effective, complete, and so on. Once a mentor is assigned, he or she is responsible as the front-line delegate of the project to manage your work, to help you with work processes, and the backstop to ensure that technical questions are answered quickly.
On the other hand, most technology and project process questions can be answered by any developer, and GSoC questions by any mentor. So in general you can post any Mailman questions here. GSoC questions can be asked on the GSoC "general" or "students" mailing lists, or here. Note that everybody in open source is stretched very thin during GSoC applications; asking questions in the right place is much more likely to get you good answers quickly. If you need authoritative answers on GSoC, Stephanie and Cat monitor the GSoC lists so you will get useful answers there.
If you're worried that other students will benefit from your questions and our answers -- this is open source, giving others the benefit of our work is the point of what we're doing! It's not just altruistic; there are mechanisms for compensating you. You still get credit for (1) openness itself and (2) working with us. If somebody steals your ball and runs off with it, they had better be just as cooperative and open or they lose points (and either way, you still maintain an edge due to being first in and getting things rolling).
And/Or Abhilash Raj, may I send you those?
I guess you can upload drafts of proposal (in google docs) on GSoC's website and we all mentors can have a look at it/comment on it if needed.
Please do register and upload a draft as soon as possible, even if very incomplete. The Google SoC system is all-new this year, and has been distinctly slow the last day or two since student applications opened. I don't expect it to crash, but if it does, *it is not an excuse for not being registered*! That's Google policy; if you don't have an application on file by the deadline date, you *cannot* become a GSoC intern. We have zero input to this policy. OTOH, we can work around incompleteness in the event of system problems.
I haven't seen the student UI, but I've heard that you can mark your proposal "draft" (or maybe you have to mark it "final", which amounts to the same thing). So you don't have to worry that an incomplete draft will count against you (in Mailman, we don't make judgments until applications close in any case).
If the draft seems *wrong* in some place, we'll let you know about that quickly. If it's still incomplete on 3/22 or so, we'll ping you about that.
To make a first impression, I thought about writing a general blog post on the state of mailinglist/group communication encryption that covers the efforts toward encrypted lists in mailman.
That's a good idea in itself, but not a substitute for a patch.
Could that work as a first impression instead of fixing a bug in mailman? The easier ones seem to get patched faster than I can catch up.
We need you to fix one easy bug so as to judge your capability to actually implement the proposal that you are proposing.
That's somewhat inaccurate. The reasons you need to fix a *Mailman* bug are
- You have to post a merge request, which means
- you know a little bit about our Gitlab repos, and
- a little bit about Gitlab, and
- have a Gitlab account.
That might not be a problem for you, but we've had issues in the past where the student floundered for a couple weeks midproject with the registration and submission procedure.
To judge implementation ability, other projects you've done or contributed to are valid evidence, of course, as long as you can point us to the code.
I can point you to several places we need more documentation ;-)
I don't care who does it (Abhilash direct-to-tracker, or Abhilash-to- Jonas-to-tracker), but please make sure all are filed on the tracker.
I was not going to exclude anyone from a discussion relevant to them or start an offtopic conversation.
I uploaded my draft yesterday, summerofcode.withgoogle.com worked after I switched from firefox to chromium. However to update the file to my local working copy – I can't help it– I had to create a new file and update the proposal url on my dashboard so please make sure to look at the most recent links. You should find my 2nd GSoC Proposal Draft on your dashboard. Any feedback would be very much appreciated.
On 18.03.2016 23:17, Abhilash Raj wrote:
We need you to fix one easy bug so as to judge your capability to actually implement the proposal that you are proposing. Although, we have mandated one patch towards your application, a small documentation patch and some of your previous patches to different projects (preferably, but not required, in Python) could work. Does that sound good? I can point you to several places we need more documentation ;-)
I would appreciate that. I guess if it doesn't neccesarily has to be merged, I will get to make a mr until friday and include it in my proposal (by now, at least my gitlab id is there). Also, if neccesary, I can show you some more very small patches I have contributed to other projects over the years, it would just take some time to dig them up.
On 19.03.2016 04:22, Stephen J. Turnbull wrote:
And/Or Abhilash Raj, may I send you those?
I guess you can upload drafts of proposal (in google docs) on GSoC's website and we all mentors can have a look at it/comment on it if needed.
Please do register and upload a draft as soon as possible, even if very incomplete. The Google SoC system is all-new this year, and has been distinctly slow the last day or two since student applications opened. I don't expect it to crash, but if it does, *it is not an excuse for not being registered*! That's Google policy; if you don't have an application on file by the deadline date, you *cannot* become a GSoC intern. We have zero input to this policy. OTOH, we can work around incompleteness in the event of system problems.
I haven't seen the student UI, but I've heard that you can mark your proposal "draft" (or maybe you have to mark it "final", which amounts to the same thing). So you don't have to worry that an incomplete draft will count against you (in Mailman, we don't make judgments until applications close in any case).
If the draft seems *wrong* in some place, we'll let you know about that quickly. If it's still incomplete on 3/22 or so, we'll ping you about that.
To make a first impression, I thought about writing a general blog post on the state of mailinglist/group communication encryption that covers the efforts toward encrypted lists in mailman.
That's a good idea in itself, but not a substitute for a patch.
Could that work as a first impression instead of fixing a bug in mailman? The easier ones seem to get patched faster than I can catch up.
We need you to fix one easy bug so as to judge your capability to actually implement the proposal that you are proposing.
That's somewhat inaccurate. The reasons you need to fix a *Mailman* bug are
- You have to post a merge request, which means
- you know a little bit about our Gitlab repos, and
- a little bit about Gitlab, and
- have a Gitlab account.
That might not be a problem for you, but we've had issues in the past where the student floundered for a couple weeks midproject with the registration and submission procedure.
To judge implementation ability, other projects you've done or contributed to are valid evidence, of course, as long as you can point us to the code.
I can point you to several places we need more documentation ;-)
I don't care who does it (Abhilash direct-to-tracker, or Abhilash-to- Jonas-to-tracker), but please make sure all are filed on the tracker.
Hey,
I have tried to update my draft according to your suggestions, Abhilash Raj and Stephen. You should see a new URL for this third draft on your dashboard. The new draft includes a merge request and more details on how I plan to implement the extension. I'm aware that I will still have to do alot of research for this to become an actual design plan. Just point me at a direction for what should be covered more closely in the proposal.
I have put a lot of work into it so if there's anything I still missed, please let me know. Especially was I wondering if the timeline looked ok and if my merge request qualified as a patch: https://gitlab.com/mailman/mailman/merge_requests/125 As a side note to this mr: I thought that it might be better to use SQL constraints (cascading) to ensure referential integrity instead of manually deleting referencing Bans, Subscriptions, Pendings etc. but it would require kind of fundamential changes and there could be database backends that don't support it.
I didn't proof read the current draft yet, I'll do that tomorrow. Anyway, I had a hard time trying to express my plans in english so remarks on my choice of words are always very welcome. Now that there's a section on implementation, a section on how I plan to do the documentation could be the next thing to add. What are your thoughts?
I would release the proposal on the project blog cryptolists.github.io after the proposal deadline has passed. Is there any reason not to?
Thank you both for your help.
Jonas writes:
I would release the proposal on the project blog cryptolists.github.io after the proposal deadline has passed. Is there any reason not to?
Privacy of proposals is entirely the student's choice. Legally, neither Google nor Mailman makes any claim to your proposal, except that you have to give permission to view to mentors and admins. Otherwise, you *own* your proposal, it's private property.
Making it public does have some advantages to the community, of course. How much that matters to you is up to you.
participants (3)
-
Abhilash Raj -
Jonas -
Stephen J. Turnbull