Re: Content security model

well, perhaps I should express my thinking like this:

   trust is not layered. it's all captured to either the intermediary
   or the server. I wish it were otherwise.

Grahame

On Thu, Jul 26, 2012 at 11:00 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> A trusted intermediary can do anything it likes and the recipient will
> accept the data (provided that the trusted intermediary
> re-authenticates it)
>
> Now the trusted intermediary may not be trustworthy, but that is a
> whole different thing entirely.
>
> On Wed, Jul 25, 2012 at 8:43 PM, Grahame Grieve <grahame@kestral.com.au> wrote:
>>> The objective should be to ensure that Web Services do not malfunction
>>> in the presence of intermediaries, not to require them to attempt to
>>> repair the damage.
>>
>> of course. But since we live in the real world too, we shouldn't prevent
>> their use to repair the damage.
>>
>>> Where security is concerned the problem is that either something is
>>> inside the authentication boundary or it is not. If it is inside the
>>> boundary it must not be modified in any way whatsoever if the
>>> integrity check is to work at all. If it is outside the boundary then
>>> the dispatch service should probably not see it at all lest it end up
>>> making assumptions that it is trustworthy.
>>
>> yes, quite. So currently there is a binary choice: you can have managed
>> interactions, or secure interactions. As you say, in an ideal world, we
>> would not need managed interactions (nor secure ones, really), But in
>> the real world we do live in, we very much need secure interactions, and
>> we also need managed ones. I'd like for the protocol to avoid making
>> this a binary choice, though it smells ugly to me.
>>
>>> What it comes down to is that intermediaries that modify HTTP messages
>>> can cause Web Services to stop working.
>>
>> oh yes, though they can also cause them to work in the first place.
>>
>>> Which is probably a good thing
>>> since it is rather unlikely that an intermediary that does not
>>> understand the semantics of the Web Service concerned is going to do
>>> anything other than introduce breakage or worse introduce a subtle
>>> error that it is not readily apparent.
>>
>> well, typically, in my world, the intermediary is a general purpose
>> toolkit introduced over the exchange with the express purpose of
>> bridging between two end-points that have very specific disagreements
>> about how things work. This is a common requirement when actually
>> integrating two off-the-shelf packages that both thought they'd implemented
>> the same semantics, but in actual case haven't. In the context of a
>> secure exchange, the general purpose toolkit gets to mount a MITM
>> attack on them too. This works until the end-to-end security becomes
>> part of the transaction semantics, at which point the MITM is no longer
>> transparent, and there is no way forward.
>>
>> Grahame
>>
>> p.s. this is obviously about application to application web services, and
>> the general argument doesn't make sense in a consumer web context.
>
>
>
> --
> Website: http://hallambaker.com/



-- 
-----
http://www.healthintersections.com.au /
grahame@healthintersections.com.au / +61 411 867 065

Received on Thursday, 26 July 2012 08:48:52 UTC