<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>Given that modern CPUs include AES support in hardware, the computational</div><div>overheads may not matter significantly. TBD based on real world testing</div><div>of course.</div><div><br></div></div></div></span></blockquote><div>You're making the assumption of AES here. I'm advocating PKI across the board. To use a symmetric cipher such as AES securely, you need a channel or session to support Diffie-Hellman, neither which we get through the RPC design. Tacking in a state machine is something I really don't want, I don't think anyone wants this.</div><div><br></div><div>A local key cache is fine. A bi-directional channel to negiotate DH keys is not, in my opinion.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div></div><div>For broadcast messages you have the problem of what key to encrypt with.</div><div>So it is probably simplest to just not encrypt broadcast messages.</div><div><br></div></div></div></span></blockquote><div>But we can sign in all instances. This is one of the reasons why I felt signing-only would be a good first step.</div><div> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div>I would be interested to know the kind of data volumes / patterns</div><div>seen for the RPC service in the real world, before ruling out the</div><div>use of x509 certs. A supposed 1.5kb overhead per call needs to be</div><div>put in context of the overall traffic & capacity before we judge</div><div>that it is unacceptable overhead. Just sending an x509 fingerprint</div><div>sounds interesting idea, but I'm not sure what security implications</div><div>that would have. One of the things I try to remember is that I'm</div><div>not Bruce Schneier, so it is best to aim for tried-and-tested design</div><div>patterns, rather than try to invent some special/clear new security</div><div>system ;-P</div></div></div></span></blockquote><div><br></div><div>Sending certificates in messages and keyserver designs should both be well trusted, conceptually. The trust is in the signature of the certificate, not the transport and storage mechanisms.</div><div><br></div><div>PGP/GPG tends to use or at least tollerates keyservers. SSL sends certificates over the wire.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>Personally I'm not so worried about the network traffic volumes.</div><div>The more important concerns to me are around the overall resillience</div><div>& computational scalability of the system. In particular making sure</div><div>you don't have to do something crazy like check keystone (or another</div><div>centralized auth service) to validate every single RPC call received.</div><div>Also trying to avoid putting any significant administrative setup or</div><div>ongoing burden on deploying openstack; retaining the flexility to</div><div>quickly re-configure the location of nova services, and the speed</div><div>with which you can react to an hostile attack and isolate compromised</div><div>services.</div></div></div></span></blockquote><div><br></div><div>In Nova, we'd be able to locally cache many of these keys. Most of our upstream lookups will be from the scheduler, verifying replies from compute nodes, since in a large enough deployment, individual schedulers will not speak to specific compute nodes frequently enough to have a cache of their key.</div><div><br></div><div>However, we shouldn't necessarily assume this to be the general pattern, as it is not a general assumption of the RPC libraries.</div><div><br></div><div>Regards,
                </div><div>Eric Windisch</div>