W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Content security model

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Wed, 25 Jul 2012 12:59:43 -0400
Message-ID: <CAMm+LwiuQu1uMuYuy_1OeS6pf5XHddgY01227h4qKN4UF7v=6w@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 July 2012 17:00:24 GMT