Re: Content security model

Those are good questions.

I guess it depends very much on what type of intermediary is involved
and whether it is a proxy type object or something 'transformational'.
In the first case the URI is going to be the same, in the second it is
going to change.

So when I design a protocol, I don't actually use the URI at all. My
server dispatch methods cannot see it, and that is exactly what I want
as I don't want the dispatcher to see anything other than the
authenticated data and the credential it is validated against.


If I wanted to pass parameters in the URI then I would make the
authentication token one of the parameters. But seriously, I never saw
the virtue of squashing your whole protocol into the request URI.

The URI line is very limited though, only 1024 bytes. Which means that
any serious service has to use url/form encoding as an option at the
very least. If you are going to pass content in the body of the
message then why not use the JSON encoding in both directions and save
some work?


As far as security goes, the model is rather different between
symmetric and asymmetric key.

With a public key protocol, the message is signed and anyone can check
the signature. This creates opportunity for endless subversion issues
as commands intended for one recipient are redirected to another. I
actually try to avoid using signatures for this very reason unless I
am writing a protocol where that is the requirement.

With a symmetric key protocol the authentication and thus the command
is inherently bound to the keys at both ends.


On Wed, Jul 25, 2012 at 8:04 PM, Manger, James H
<James.H.Manger@team.telstra.com> wrote:
>> > 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.
>
> What about the URI?
> What about the method (GET, POST, DELETE...)?
>
> Only protecting the body only works for RPC-style web services in which every request is a POST to a single API endpoint (eg POST /api/ HTTP/1.1). Even then the body needs to have an "audience" field that is likely to repeat the host (or URI).
>
> HTTP/2 needs to support REST APIs, where the method and URI are crucial parts.
>
>> > From these I draw the following conclusions:
>> >
>> > * HTTP 2.0 should draw a distinction between routing headers and
>> >   content meta-data
>
> +1
> Though I suspect there are lots of headers where this distinction is not crystal clear.
>
>> > * HTTP encryption and authentication are necessary independent of TLS
>> >   support
>
> --
> James Manger



-- 
Website: http://hallambaker.com/

Received on Thursday, 26 July 2012 00:28:20 UTC