Re: Content security model

On Wed, Jul 25, 2012 at 9:59 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> 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
>

Actually, TLS is end-to-end encrypted and just an opaque byte stream as far
as intermediaries are concerned.  I'm not sure what you mean by hop-by-hop,
but TLS is not (to me) hop-by-hop.


> 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.
>

I don't think multiplexing has impact on this.  If HTTP/2.0 (with
multiplexing) is truly transparent, then the higher level message
transformations are identical with or without mux.


>
> 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.
>

Like a cookie?  We can retroactively try to claim cookies are wrong, but
that doesn't help the millions of services that employ them today.

I think you're just differentiating the securing of the stream (which is
what TLS does) from the securing of the content (some sort of signing).
 These are independent and can be mixed and matched.

Mike






>
>
> 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/
>
>