Open Stack

On Tue, 2013-04-30 at 13:55 +0100, Mark McLoughlin wrote:
> 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.

Ok, notifications were not in scope for my document, so I will ignore
this problem for now.

Once we have something in place and can play with it it will be easier
to make changes and see what works, worst case we introduce public key
for signing of notifications on top or instead of the current proposal.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York