[chef] Re: Re: Re: Re: Re: Re: New Authentication in Chef 0.8

[Miguel Cabeça < >]

> It's not crazy to imagine a world where requests are accepted via
> HTTPS, and then get relayed to their final destination via AMQP.  By
> relying on TLS, you make it very difficult for that final endpoint to
> verify that the message it received is the one sent by the original
> endpoint.
> 
> The source of our disagreement is that I don't think we should force
> decisions about the transport layer in order to gain a perceived
> benefit of simplicity in the application layer.  By signing each
> request, we gain the ability to, at any link in the chain, verify that
> the request has not been tampered with.  We gain a huge amount of
> application architecture flexibility, and it's applicable to a much
> wider range of problems.
> 
> You're assuming a point-to-point, one client to single host
> architecture.  You *can* build an application that relies on transport
> layer authentication for security, and by doing so you add the
> constraint that it *must* have all communication occur over that
> transport layer.  By digitally signing each request, we gain the
> flexibility of being able to re-use that functionality across any
> transport layer, to serialize and distribute requests in any way we
> see fit, and to continually ensure that the payload is *exactly as it
> was created by the signing client*, regardless of intervening
> transport layers.
> 
> Imagine a scenario where you start building orchestration
> functionality around Chef, where each client is gossiping about it's
> current status ("I'm at step one!  I'm at step two!  I'm the
> master!").  In a world where we only had TLS for client
> authentication, each of those messages would need to be either sent
> via a specific point-to-point connection with every other member of
> the quorum, or coordinated through a central server.
> 
> In a world where each client signs their own payloads, you have lots
> of options.  The clients themselves can gossip about their public
> keys, they can sign the payload of each gossip request, and they can
> do it via multi-cast.
> 
> I agree that it might not have been necessary for the use case you
> have foremost in your mind (which is a single chef client
> communicating with a remote chef server over HTTPS,) but I think it
> was absolutely necessary for a huge number of other use cases.

Thank you for the time you spent explaining this to me. I finally got the 
benefit of this approach. If you'd only mentioned "payload relaying" and 
"end-to-end authentication through multiple hop communication" earlier :-)


Best Regards

Miguel Cabeça