W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: Trusted Proxy Alternatives Analysis

From: Peter Lepeska <bizzbyster@gmail.com>
Date: Fri, 7 Feb 2014 10:00:01 -0500
Message-ID: <CANmPAYF372s5qk0K-awTu3O41-PE8BRKWKFrkybbqTH+yBqdMw@mail.gmail.com>
To: Frode Kileng <frodek@tele.no>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Hi Frode,

I would like to faithfully update the table to reflect the groups thoughts
on this but I have to say I'm confused by what you are proposing. When you
say this "Regarding the "identity binding", an alternative is of course to
do this end-2-end." aren't you essentially saying that this could be solved
by reverse proxy / CDN? Which is what I've already put in the Alternatives
column for the Mike's Music Service use case.

Maybe I need to clarify some assumptions about forward versus reverse
proxy. In general, unlike a forward proxy, a reverse proxy is deployed by
the content owner or the content owner partner ("CDN") and so has the
private keys and so does not need to ask the user for "trust" in order to
decrypt the data.

Does that clarify anything?



On Fri, Feb 7, 2014 at 6:54 AM, Frode Kileng <frodek@tele.no> wrote:

> Hi Emilie
> On 07.02.2014 12:23, emile.stephan@orange.com wrote:
> > Hi Frode,
> >
> >  The term MITM in not appropriate for these cases: the service
> augmentation
> >  is performed by the reverse proxy of the mobile operator. This reverse
> proxy
> >  receives and processes the requests for the service provided by the
> mobile
> >  operator.
> Is the client configured to use this proxy? If not, I prefer to use MITM
> although the wording may not be the the most important isue...
> Regarding the "identity binding", an alternative is of course to do this
> end-2-end. If this for some reason isn't an alternative, I would propose
> that the use case description clearly states why, both in regard to
> end-user experience ("User benefit") and/or service/network provider issues
> ("Admin Benefit").
> Regards
> Frode Kileng
Received on Friday, 7 February 2014 15:00:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC