Re: [asterisk-users] Security communication dilemma: your help needed
On Sat, 10 Jan 2009, Kevin P. Fleming wrote: John Todd wrote: Desired procedure: A public key signature method would be publicly available via an SSL web page or various keyservers. Individuals could sign messages with the public key. Signed messages sent to security@ would then be decrypted, and re-encrypted with the security@ key and sent to the small list of end recipients. Any recipients who replied back to the message would have the process happen in reverse, and also have copies if the reply sent (encrypted) to the other members of this email exploder as well as the external author. Actually, a slight clarification is in order. Let's assume for the moment that the security@ role is actually serviced by developers A, B, C and D (not necessarily all Digium employees, but Asterisk developers). Let's also assume that third-party X wants to send a secure vulnerability report. 1) X retrieves the security@ public key from a reliable source; this key would be countersigned by a large number of Asterisk developers to ensure its authenticity. 2) X would compose their message, attach their GPG public key, digitally sign the message using their GPG private key, then encrypt the entire message using the security@ public key. 3) The message would be received by this super-duper email alias processor, which would then (because it has the security@ private key), decrypt the message, verify the signature from X, then store X's public key in a local database along with some sort of thread ID for this conversation. 4) The processor would then re-send the message to A, B, C and D, in each case signing the message using the security@ public key and encrypting it using the recipient's public key, so each copy of the message leaving the processor can only be read by the recipient. 5) If A, B, C or D responds to the message (back to the security@ processor), they would also sign/encrypt their response, and the same process would occur. However, since the processor would have the thread ID (presumably in a References or In-Reply-To header in the reply), it would also include X in the distribution of the reply, encrypting the message using X's stored public key. This sounds perfect. So what is missing? Just the super list processor? j ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Security communication dilemma: your help needed
Jeff LaCoursiere wrote: This sounds perfect. So what is missing? Just the super list processor? Yep... we're looking for either an existing tool, or someone interested in coding up some Perl/PHP/Python/Ruby/etc. to be run as a delivery agent for an MTA and do the message acceptance/routing. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Security communication dilemma: your help needed
John Todd wrote: Desired procedure: A public key signature method would be publicly available via an SSL web page or various keyservers. Individuals could sign messages with the public key. Signed messages sent to security@ would then be decrypted, and re-encrypted with the security@ key and sent to the small list of end recipients. Any recipients who replied back to the message would have the process happen in reverse, and also have copies if the reply sent (encrypted) to the other members of this email exploder as well as the external author. Actually, a slight clarification is in order. Let's assume for the moment that the security@ role is actually serviced by developers A, B, C and D (not necessarily all Digium employees, but Asterisk developers). Let's also assume that third-party X wants to send a secure vulnerability report. 1) X retrieves the security@ public key from a reliable source; this key would be countersigned by a large number of Asterisk developers to ensure its authenticity. 2) X would compose their message, attach their GPG public key, digitally sign the message using their GPG private key, then encrypt the entire message using the security@ public key. 3) The message would be received by this super-duper email alias processor, which would then (because it has the security@ private key), decrypt the message, verify the signature from X, then store X's public key in a local database along with some sort of thread ID for this conversation. 4) The processor would then re-send the message to A, B, C and D, in each case signing the message using the security@ public key and encrypting it using the recipient's public key, so each copy of the message leaving the processor can only be read by the recipient. 5) If A, B, C or D responds to the message (back to the security@ processor), they would also sign/encrypt their response, and the same process would occur. However, since the processor would have the thread ID (presumably in a References or In-Reply-To header in the reply), it would also include X in the distribution of the reply, encrypting the message using X's stored public key. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Security communication dilemma: your help needed
Hi On Sat, Jan 10, 2009 at 06:38:45AM -0600, Kevin P. Fleming wrote: John Todd wrote: Desired procedure: A public key signature method would be publicly available via an SSL web page or various keyservers. Individuals could sign messages with the public key. Signed messages sent to security@ would then be decrypted, and re-encrypted with the security@ key and sent to the small list of end recipients. Any recipients who replied back to the message would have the process happen in reverse, and also have copies if the reply sent (encrypted) to the other members of this email exploder as well as the external author. Actually, a slight clarification is in order. Let's assume for the moment that the security@ role is actually serviced by developers A, B, C and D (not necessarily all Digium employees, but Asterisk developers). Let's also assume that third-party X wants to send a secure vulnerability report. 1) X retrieves the security@ public key from a reliable source; this key would be countersigned by a large number of Asterisk developers to ensure its authenticity. 2) X would compose their message, attach their GPG public key, digitally sign the message using their GPG private key, then encrypt the entire message using the security@ public key. Suggested modification) X also signs the message with his public key. (If X doesn't want to, this automated procedure will not apply) 3) The message would be received by this super-duper email alias processor, which would then (because it has the security@ private key), decrypt the message, verify the signature from X, then store X's public key in a local database along with some sort of thread ID for this conversation. The security alias processor has in its keyring the approved public keys. If the signature passes, the mail can be simply forwarded as-is. If not, we need the extra verification ping-pong (step 4 below). Rationale: I wouldn't want this delay for every message I send through the alias. 4) The processor would then re-send the message to A, B, C and D, in each case signing the message using the security@ public key and encrypting it using the recipient's public key, so each copy of the message leaving the processor can only be read by the recipient. A verified key will also be added to the alias processor's keyring. We should see how to sync that keyring to A, B, C and D. 5) If A, B, C or D responds to the message (back to the security@ processor), they would also sign/encrypt their response, and the same process would occur. However, since the processor would have the thread ID (presumably in a References or In-Reply-To header in the reply), it would also include X in the distribution of the reply, encrypting the message using X's stored public key. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Security communication dilemma: your help needed
Tzafrir Cohen wrote: Suggested modification) X also signs the message with his public key. (If X doesn't want to, this automated procedure will not apply) I don't understand; if X signs the message using his public key, then recipients would need X's private key to verify the signature. Who would have that besides X? The security alias processor has in its keyring the approved public keys. If the signature passes, the mail can be simply forwarded as-is. No, it can't. It has to be sent onwards to the recipients in encrypted form, and the original message can't be sent to them because they don't have the private key to use to decrypt the message (they would all need the security@ private key to do so). Rationale: I wouldn't want this delay for every message I send through the alias. I don't imagine this would take more than a minute to process a message. It would hardly be noticeable. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Security communication dilemma: your help needed
On Sat, Jan 10, 2009 at 10:04:53AM -0600, Kevin P. Fleming wrote: Tzafrir Cohen wrote: Suggested modification) X also signs the message with his public key. (If X doesn't want to, this automated procedure will not apply) I don't understand; if X signs the message using his public key, then recipients would need X's private key to verify the signature. Who would have that besides X? Many people publish their public key on keyservers. The security alias processor has in its keyring the approved public keys. If the signature passes, the mail can be simply forwarded as-is. No, it can't. It has to be sent onwards to the recipients in encrypted form, and the original message can't be sent to them because they don't have the private key to use to decrypt the message (they would all need the security@ private key to do so). This means that the message can no longer be signed. Rationale: I wouldn't want this delay for every message I send through the alias. I don't imagine this would take more than a minute to process a message. It would hardly be noticeable. It makes email interactive. Email (by nature) isn't. I hate it when I have to confirm everything. Even more so when I have to do it every time around. Use XMPP instead. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Security communication dilemma: your help needed
Tzafrir Cohen wrote: On Sat, Jan 10, 2009 at 10:04:53AM -0600, Kevin P. Fleming wrote: Tzafrir Cohen wrote: Suggested modification) X also signs the message with his public key. (If X doesn't want to, this automated procedure will not apply) I don't understand; if X signs the message using his public key, then recipients would need X's private key to verify the signature. Who would have that besides X? Many people publish their public key on keyservers. Umm... you didn't answer my question! You proposed that X would sign the message using his *public* key. Doing so requires that the recipients of the message use his *private* key to verify the signature, since this is asymmetric key encryption. Normally when an email message is signed, the signature is created using the signer's private key, and the public key is used to verify the signature. This is what I proposed in the original message. The security alias processor has in its keyring the approved public keys. If the signature passes, the mail can be simply forwarded as-is. No, it can't. It has to be sent onwards to the recipients in encrypted form, and the original message can't be sent to them because they don't have the private key to use to decrypt the message (they would all need the security@ private key to do so). This means that the message can no longer be signed. Why? It can be signed by the email processor so that A, B, C and D know that it's a validly forwarded message, and the fact that the processor forwarded it means the processor validated the signature from X on the original message. This is a chain of trust that we'd be satisfied with. Rationale: I wouldn't want this delay for every message I send through the alias. I don't imagine this would take more than a minute to process a message. It would hardly be noticeable. It makes email interactive. Email (by nature) isn't. I hate it when I have to confirm everything. Even more so when I have to do it every time around. What would you have to confirm? You'd receive a message from security@, which was signed and encrypted using keys you have in your keyring. Your email client will offer to decrypt the message, and then verify the signature. This is exactly the same as receiving any other encrypted message, there is no 'confirmation' or interactivity. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Security communication dilemma: your help needed
Kevin P. Fleming wrote: Tzafrir Cohen wrote: Suggested modification) X also signs the message with his public key. (If X doesn't want to, this automated procedure will not apply) I don't understand; if X signs the message using his public key, then recipients would need X's private key to verify the signature. Who would have that besides X? Generally an encrypted message is signed with the private key and decrypted with the public key, the point of public key encryption is not to hide the content of the message, but rather to insure that the content was not altered during transmission. Anthony ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Security communication dilemma: your help needed
Dilemma: Digium will sometimes receive requests to send GPG-encrypted mail dealing with security issues. This works somewhat poorly for email role accounts where there are multiple recipients on a single address. If there exists a better way to do this that doesn't involve a lot of customization, let me know and we'll see if it will do the right thing, otherwise we'll continue with the functional but somewhat awkward current method. Current procedure: An individual will reply back, and create a 1:1 signed exchange with the original correspondent. Then, the Digium staffer will relay the data (with relevant GPG keys) to each other Digium staff member who may be involved. Desired procedure: A public key signature method would be publicly available via an SSL web page or various keyservers. Individuals could sign messages with the public key. Signed messages sent to security@ would then be decrypted, and re-encrypted with the security@ key and sent to the small list of end recipients. Any recipients who replied back to the message would have the process happen in reverse, and also have copies if the reply sent (encrypted) to the other members of this email exploder as well as the external author. Summary: Has anyone implemented a B2BUA for GPG-signed email? JT --- John Todd email:jt...@digium.com Digium, Inc. | Asterisk Open Source Community Director 445 Jan Davis Drive NW - Huntsville AL 35806 - USA direct: +1-256-428-6083 http://www.digium.com/ ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Security communication dilemma: your help needed
On Fri, Jan 09, 2009 at 04:05:01PM -0500, John Todd wrote: Dilemma: Digium will sometimes receive requests to send GPG-encrypted mail dealing with security issues. This works somewhat poorly for email role accounts where there are multiple recipients on a single address. If there exists a better way to do this that doesn't involve a lot of customization, let me know and we'll see if it will do the right thing, otherwise we'll continue with the functional but somewhat awkward current method. Current procedure: An individual will reply back, and create a 1:1 signed exchange with the original correspondent. Then, the Digium staffer will relay the data (with relevant GPG keys) to each other Digium staff member who may be involved. Desired procedure: A public key signature method would be publicly available via an SSL web page or various keyservers. Individuals could sign messages with the public key. Signed messages sent to security@ would then be decrypted, and re-encrypted with the security@ key and sent to the small list of end recipients. Any recipients who replied back to the message would have the process happen in reverse, and also have copies if the reply sent (encrypted) to the other members of this email exploder as well as the external author. The output of this is a keyring, that you can later import to your own personal keyring. See also the Debian package debian-maintainers for a slightly different approach. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
