Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

On 25.04.2013 21:10, Abhilash Raj wrote:
May I suggest that mailman doesn't create the list key by itself, but ask the list maintainer to upload a public/private key pair (if no crypto hardware is used, see below)? On a virtualized system, getting real randomness is tricky.
I would distinguish the following two scenarios:
The list is not-so-high-sec that you can risk storing the secret key without a password (which is the equivalent to storing the passphrase in the database).
Your list has elevated security requirements. In this case, you can use gpg-agent to manage the secret key (and its passphrase). This would require the sysadmin to start the gpg-agent and enter the list's passphrase before firing up mailman (or mailman could queue incoming mails until the secret key becomes available). This would open you the option to have the mailing list's secret key on a hardware token (e.g. the CryptoStick http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=133).
Stefan.

Stefan Schlott writes:
I don't understand what threat you propose to address in this way. It's true that you can prevent the attacker from getting access to the key (using agent forwarding or a token, it need not be on the exposed host at all), but we're assuming he has access to the host and the Mailman process.
At a minimum you need some kind of privilege separation mechanism within Mailman. I'd recommend a postfix-style separate process which does all cryptographic work. But this might be a very large performance hit.

On 04/27/2013 12:45 PM, Stephen J. Turnbull wrote:
If mailman is storing messages on-disk in an encrypted form, Stefan's proposal mitigates the threat of an adversary with offline access to the disk (e.g. in the event of server theft or seizure) -- no additional message content will be revealed if such an adversary scrapes the contents of the disk.
--dkg

On 27.04.2013 06:45, Stephen J. Turnbull wrote:
The gpg-agent approach protects you from all storage-related attacks:
- unencrypted backups
- physical access to the harddrive
- etc.
It does not protect from attackers who have access to the contents of the computer's RAM:
- raw memory access and scanning for the secret key (requires root)
- memory dump via DMA-enabled interfaces (firewire, pc-card, ...)
- cold boot attacks
Stefan.

I don't think that "we" have the expertise to create a "secure" system. At best, we can adopt good practices and provide an obscured traffic stream. I consider anything more to be beyond the scope of the MM project.
On Apr 27, 2013, at 8:22 AM, Stefan Schlott <stefan.schlott@ulm.ccc.de> wrote:

On 27 Apr 2013, at 14:40, Richard Wackerbarth <rkw@dataplex.net> wrote:
I don't think that "we" have the expertise to create a "secure" system. At best, we can adopt good practices and provide an obscured traffic stream. I consider anything more to be beyond the scope of the MM project.
Also, what kind of secure list would have automated processing of message content as a requirement? If a message is gpg encrypted, then every sender would require the public keys of every recipient, would they not? Which means that a PKI for the list holders is required. Currently outside of Mailman's scope, but if it exists, then presumably senders would be required to cryptographically sign every message. All the list needs to do is verify the signature before redistributing. THAT is going to be the main body processing requirement.
-- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148

On 29.04.2013 11:40, Ian Eiloart wrote:
Also, what kind of secure list would have automated processing of message content as a requirement?
imho you're asking the wrong question ;-) _All_ network communication should be encrypted, it is a pity that mail encryption is so little adopted.
No. The idea here that the recipient of a mail sent to a mailing list is the (trusted) mailman server, thus the only key needed is the mailing list public key. Mailman has access to its secret key, decrypts the incoming message and re-encrypts it for each recipient.
Stefan.

Ian Eiloart writes:
Also, what kind of secure list would have automated processing of message content as a requirement?
Precisely, a list that wants to avoid this requirement:
If a message is gpg encrypted, then every sender would require the public keys of every recipient, would they not?
The idea is that senders use the list's public key. The list holds those public keys, and uses them to re-encrypt the message on a recipient-by-recipient basis after decrypting with its own private key.
The discussion has been about how to deal with attacks on (a) the list's private key (including offline attacks on the hard drive) and on (b) the temporarily decrypted text (which could end up in the clear for a long time in a queue file or if Mailman crashes).

On 4/29/13 5:40 AM, Ian Eiloart wrote: list's public key, and the list decrypts the message and then reencrypts to each recipient's public key. (In many cases this doesn't actually require decrypting/reencrypting the whole message, just the session key block).
The list could also check any signature, and sign messages with valid signatures with it's key.
That way, subscribers don't need any other subscriber's public key. In fact, I think the list could even be set up anonymous so you might not even know who anyone else was, just that the list has validated that the message came from someone on the list.
-- Richard Damon

Stefan Schlott writes:
I don't understand what threat you propose to address in this way. It's true that you can prevent the attacker from getting access to the key (using agent forwarding or a token, it need not be on the exposed host at all), but we're assuming he has access to the host and the Mailman process.
At a minimum you need some kind of privilege separation mechanism within Mailman. I'd recommend a postfix-style separate process which does all cryptographic work. But this might be a very large performance hit.

On 04/27/2013 12:45 PM, Stephen J. Turnbull wrote:
If mailman is storing messages on-disk in an encrypted form, Stefan's proposal mitigates the threat of an adversary with offline access to the disk (e.g. in the event of server theft or seizure) -- no additional message content will be revealed if such an adversary scrapes the contents of the disk.
--dkg

On 27.04.2013 06:45, Stephen J. Turnbull wrote:
The gpg-agent approach protects you from all storage-related attacks:
- unencrypted backups
- physical access to the harddrive
- etc.
It does not protect from attackers who have access to the contents of the computer's RAM:
- raw memory access and scanning for the secret key (requires root)
- memory dump via DMA-enabled interfaces (firewire, pc-card, ...)
- cold boot attacks
Stefan.

I don't think that "we" have the expertise to create a "secure" system. At best, we can adopt good practices and provide an obscured traffic stream. I consider anything more to be beyond the scope of the MM project.
On Apr 27, 2013, at 8:22 AM, Stefan Schlott <stefan.schlott@ulm.ccc.de> wrote:

On 27 Apr 2013, at 14:40, Richard Wackerbarth <rkw@dataplex.net> wrote:
I don't think that "we" have the expertise to create a "secure" system. At best, we can adopt good practices and provide an obscured traffic stream. I consider anything more to be beyond the scope of the MM project.
Also, what kind of secure list would have automated processing of message content as a requirement? If a message is gpg encrypted, then every sender would require the public keys of every recipient, would they not? Which means that a PKI for the list holders is required. Currently outside of Mailman's scope, but if it exists, then presumably senders would be required to cryptographically sign every message. All the list needs to do is verify the signature before redistributing. THAT is going to be the main body processing requirement.
-- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148

On 29.04.2013 11:40, Ian Eiloart wrote:
Also, what kind of secure list would have automated processing of message content as a requirement?
imho you're asking the wrong question ;-) _All_ network communication should be encrypted, it is a pity that mail encryption is so little adopted.
No. The idea here that the recipient of a mail sent to a mailing list is the (trusted) mailman server, thus the only key needed is the mailing list public key. Mailman has access to its secret key, decrypts the incoming message and re-encrypts it for each recipient.
Stefan.

Ian Eiloart writes:
Also, what kind of secure list would have automated processing of message content as a requirement?
Precisely, a list that wants to avoid this requirement:
If a message is gpg encrypted, then every sender would require the public keys of every recipient, would they not?
The idea is that senders use the list's public key. The list holds those public keys, and uses them to re-encrypt the message on a recipient-by-recipient basis after decrypting with its own private key.
The discussion has been about how to deal with attacks on (a) the list's private key (including offline attacks on the hard drive) and on (b) the temporarily decrypted text (which could end up in the clear for a long time in a queue file or if Mailman crashes).

On 4/29/13 5:40 AM, Ian Eiloart wrote: list's public key, and the list decrypts the message and then reencrypts to each recipient's public key. (In many cases this doesn't actually require decrypting/reencrypting the whole message, just the session key block).
The list could also check any signature, and sign messages with valid signatures with it's key.
That way, subscribers don't need any other subscriber's public key. In fact, I think the list could even be set up anonymous so you might not even know who anyone else was, just that the list has validated that the message came from someone on the list.
-- Richard Damon
participants (7)
-
Daniel Kahn Gillmor
-
Ian Eiloart
-
Richard Damon
-
Richard Wackerbarth
-
Stefan Schlott
-
Stefan Schlott
-
Stephen J. Turnbull