- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Wed, 25 Jul 2012 21:00:02 -0400
- To: grahame@healthintersections.com.au
- Cc: James French <jfrench@denirostaff.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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/
Received on Thursday, 26 July 2012 01:00:31 UTC