- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Wed, 25 Jul 2012 12:59:43 -0400
- To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
I have been thinking a lot about Web Services and how their security needs should be met in HTTP/2.0. I came up with some thoughts that might provoke discussion: 0) The killer application for HTTP/2.0 (if any) is going to be Web Services. Anyone supporting a Web server is going to have to support /1.1 for decades to come. A new Web Service can stipulate HTTP/2.0 transport as a requirement. 1) TLS security is good for what it does, but it is still transport security and will therefore be hop-by-hop as far as intermediaries are concerned. This gives rise to the need for security features in HTTP that are orthogonal to TLS and can survive passage through an intermediary. 2) Multiplexing changes the nature of Web Services security and allows for a significant simplification. Under HTTP/1.1 a Web Service that takes a message from A and forwards it to B has to modify the content if it is going to provide additional information in the transaction. This constraint no longer applies under multiplexing. 3) HTTP security controls should only secure content. Signing headers is not only difficult, it is often counterproductive. If a Web service depends on information in a header there is probably something wrong. This last one might seem a little controversial, after all, doesn't DKIM have a mechanism for header signing? DKIM does have a header signing mechanism but the headers being signed should probably have been content in the first place. The subject line, From, To, these are all message content. They are part of the headers because content and routing are conflated in SMTP email. HTTP does have a similar conflation, but nowhere near as severe. Content is mostly confined to the body and Routing is strictly confined to the Head. The parts that cross the line are Content-Encoding and Content-Type. Both of which are ignored in a Web Services context almost all the time. Yes, a Web Service could support multiple character encodings but I cannot see any case where I would want the service to use Content-Encoding to make the choice. >From these I draw the following conclusions: * HTTP 2.0 should draw a distinction between routing headers and content meta-data * HTTP encryption and authentication are necessary independent of TLS support -- Website: http://hallambaker.com/
Received on Wednesday, 25 July 2012 17:00:13 UTC