Open Stack

On Tue, 2013-04-30 at 08:49 -0400, Simo Sorce wrote:
> On Tue, 2013-04-30 at 13:45 +0100, Mark McLoughlin wrote:
> > On Tue, 2013-04-30 at 08:36 -0400, Simo Sorce wrote:
> > > On Tue, 2013-04-30 at 13:34 +0100, Mark McLoughlin wrote:
> > > > On Tue, 2013-04-30 at 08:27 -0400, Simo Sorce wrote:
> > > > > On Tue, 2013-04-30 at 12:03 +0100, Mark McLoughlin wrote:
> > > > > > Hi Simo,
> > > > > > 
> > > > > > On Thu, 2013-04-25 at 08:37 -0400, Simo Sorce wrote:
> > > > > > > Hello list,
> > > > > > > at the Summit we had a very interesting and productive discussion about
> > > > > > > Message Signing/Encryption for RPC Messages sent via the Message Queue.
> > > > > > > 
> > > > > > > I would like to present a proposal that uses symmetric keys and a
> > > > > > > central key server to address the problem:
> > > > > > > 
> > > > > > > https://wiki.openstack.org/wiki/MessageSecurity
> > > > > > > 
> > > > > > > I would really like to get feedback on the proposal, especially if there
> > > > > > > are corner cases I have not considered.
> > > > > > 
> > > > > > I admit I haven't spent much time considering all aspects of this, but
> > > > > > from a high level I like the idea and your diligence.
> > > > > > 
> > > > > > I'm working on a proposal for a redesign of the messaging API:
> > > > > > 
> > > > > >   https://wiki.openstack.org/wiki/Oslo/Messaging
> > > > > > 
> > > > > > I don't think this will affect your design in any way, and I don't think
> > > > > > your proposal changes the API design ... so that's all goodness.
> > > > > > 
> > > > > > One thing I've just realized we haven't taken into account is
> > > > > > notifications. There's probably a lot of value (to ceilometer at least,
> > > > > > I'd imagine) in using public-key encryption to sign those messages since
> > > > > > they are being broadcast to the world and there's no concept of the
> > > > > > sender knowing who the message is being sent to.
> > > > > > 
> > > > > > Maybe solving the notification signing issue is orthogonal to RPC
> > > > > > signing and encryption, but had you any thoughts on it?
> > > > > 
> > > > > I was under the impression that broadcasting to the world is a bad idea.
> > > > 
> > > > Ok, "broadcasting on a message bus that requires credentials to access".
> > > > 
> > > > An example would be a cloud operators fault analysis tool listening on
> > > > the bus for error events, applying some logic and alerting the right
> > > > people.
> > > 
> > > I think just for detection you could simply ignore signing and rely on
> > > the message queue ?
> > > Do you need to protect from spoofing for this task ?
> > 
> > Ceilometer is the other example, and the ability to spoof notifications
> > gives you the ability to cause someone to be incorrectly billed ... so,
> > yeah, I think it would be valuable to be able to trust that
> > notifications can't be spoofed even if the message queue is compromised.
> 
> How will ceilometer deal with encryption ?
>
> Wouldn;t it be better to send messages explicitly to ceilometer (would
> allow to send encrypted too) for billing rather than relying on signed
> only (but not encrypted) messages and broadcast ?
> 
> For some things you may want to bill you will also want to encrypt the
> message.

I don't see a case where encryption would be a big benefit, but maybe
Ceilometer folks would have an example.

One of the benefits I see in the notification system is that the sender
of notifications don't need to be aware of who's consuming them.

Cheers,
Mark.