Open Stack

> 
> I don't think he was advocating a matchmaker requirement. In fact, we
> spoke about this specifically. The idea is what in cases when we're
> sending a specific service+host, the key used reflects that. In the
> case where we're sending to any one of a specific service, the key is
> service-wide. Is that acceptable? Maybe. We have to look at when each
> case is used.


I don't think it is acceptable. Shared private keys aren't private.

Also, you eliminate the ability to prevent replay attacks if the peer is not known in advance. Despite what I said earlier, this does mean that for PKI, if strict replay attack prevention is enforced, one will need to use the matchmaker for signing. However, at least then, that is a soft-requirement, something a deployer can choose: risk of replay versus performance.

Having individual keying allows for things like tying your keyserver into remote attestation. Hosts that cannot attest can be removed from the pool automatically.

You want one compromised scheduler to remove them all? If using some plugin to Quantum that required a fanout to all compute, should one compromised compute machine disable them all?

> In nova, the case that we're *most* concerned about is anything
> involving compute nodes. In the case of compute, we're almost always
> talking directly to a specific compute node. There's one case where we
> broadcast to all computes, but I think we can probably re-engineer that
> case.

What about Quantum? Cinder? Ceilometer?

Quantum seems to require agents on all compute nodes. Several plugins perform fanout calls to those agents. Yes, seriously. That might not be a good design, but they do it.
> A service-wide example would be scheduler. We're not nearly as
> concerned about the scheduler, so a key for scheduler.* is probably
> acceptable.
> 

I disagree. 

Regards,
Eric Windisch