[openstack-dev] [nova][keystone] Message Queue Security

Eric Windisch eric at cloudscaling.com
Thu Apr 25 16:52:44 UTC 2013

I've read through this and had a discussion with Simo on IRC for clarity, before posting.

It isn't a terrible proposal. My biggest concerns are the following, as pertains to signing-only:

1) Keyserver lookups on both sides, not just one-sided, on signing.
2) Practical requirement for the matchmaker for signing, even for AMQP.

On the encryption side, PKI has the same requirements, but using slower algorithms. If we accept that the typical use-case will be message signing, then we may prefer to optimize for that, not for encryption. Perhaps we could figure out a middle-ground here with a single sender-side lookup and a token from the keyserver? That might be a slippery slope.

The practical requirement for the matchmaker is a HUGE one. This means that not only does a keyserver lookup have to be performed when sending each message, but also a matchmaker lookup. The matchmaker would perform local routing decisions, rather than making those decisions on a broker. These routing decisions must be made locally such that the peers on both sides of the connection are known in advance, for keying purposes.

This is already the case with ZeroMQ, for which it is a necessity, but it is not presently the case for AMQP. Demanding the use of the matchmaker for AMQP eliminates most, if not every, advantage that one might perceive out of Rabbit/Qpid (as presently designed). Basically, ZeroMQ starts to look a hell of a lot more attractive in this model, to the degree that it would become silly to consider running our present Rabbit/Qpid drivers with signing enabled.

Of course, the Rabbit/Qpid drivers could be rewritten for a distributed broker model, mirroring what we have with ZeroMQ.

Hell, I'm the ZeroMQ driver maintainer - I don't mind if everyone wants to switch to ZeroMQ, or switch to the messaging model it advocates. I'd be happy for it. However, I'm not the one suggesting we do this - but the community should realize that Simo is effectively, whether he knows it or not, pushing for either the adoption of ZeroMQ or the rewrite of our RabbitMQ/Qpid drivers. It might not be obvious now, but that is the path this particular road leads to. It isn't a bad road, but we shouldn't be surprised when we get to the end.

The proposal to use PKI for signing, despite what might otherwise be complexities and difficulties around that proposal, would not significantly change our messaging model. This kind of gets thrown out as soon as we introduce encryption, however, where we fall back into the matchmaker trap such that we can determine the remote peer's identity for encryption purposes.

Eric Windisch

On Thursday, April 25, 2013 at 08:37 AM, 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.
> Simo.
> -- 
> Simo Sorce * Red Hat, Inc * New York
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org (mailto:OpenStack-dev at lists.openstack.org)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list