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

Re: Content security model

From: Grahame Grieve <grahame@kestral.com.au>
Date: Thu, 26 Jul 2012 10:43:51 +1000
Message-ID: <CAG47hGZLN4w7+m370h=OupXQc6ZJ_r2idQ3hP1yhxD0Fi9mLWA@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: James French <jfrench@denirostaff.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
> 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.


p.s. this is obviously about application to application web services, and
the general argument doesn't make sense in a consumer web context.
Received on Thursday, 26 July 2012 00:44:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:04 UTC