Is there a benefit from the encryption support in the protocol, if the major use cases don't need to worry about what the intermediates see? You mean payload encryption? Or generally “hide” information and possibilities for secondary servers to meddle with payload? Generally speaking, making the protocols useful for different usages is always nice- I tend to see the OOB&Co protocols as a toolbox where one pick the mechanisms that is suitable for use case at hand. So if you 100% trust that CDN, operator proxy, enterprise proxy, (someone else ) edge data centre where you deploy your secondary server, then you may decide not to encrypt (or give it the key). If you don’t, why not use payload protection (encryp/integrity protect) or even do not deliver the resource OOB. It’s a matter of how much trust you put into the secondary server, the cloud platform (actor) you run it on and the data centre (provider’s site security) where it is placed. So yes, having the option is useful I would say and whether one can/should trust intermediaries in the delivery from origin to client, even if it’s the service providers “own” intermediary can be discussed. Be well! Göran
Received on Saturday, 26 August 2017 10:24:11 UTC