Open Stack

On Thu, 2013-04-25 at 12:52 -0400, Eric Windisch wrote:
> 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.

Signing is also very slow with public key crypto as it is the same
operation only using the other key (private vs public).

> 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.

I have looked into this claim after our conversation and I am not so
sure we really need it. At least not always.

For communication to services that are duplicated just for scalability,
like the scheduler, using a shared short term key that they can all
request from the key server is probably fine. The schedulers are all
allowed to send messages to the compute nodes anyway, so if any get
compromised it is already game over.
So we could easily have a target of scheduler.* and no matchmaker would
be required.

The only "service" we do not want to allow to share keys is the compute
node, but fanning out to compute nodes is already a bad idea, so
limiting that target, or simply not signing those kind of broadcast
messages until a better approach is found is probably ok.

One minor issue is handling replay attacks, but the same issue exists
unaltered in a public key crypto approach.

[..]

> 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.

I think this is a gross misrepresentation, sorry.

>  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.

Except my proposal allows encryption to multiple parties, they just have
to share a short term key, while a public key infrastructure simply
cannot do that, because you'd have to share a long term key.

So pick your poison :)

Simo.

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