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

Re: New Version Notification for draft-nottingham-http-proxy-problem-01.txt

From: Phil Hunt <phil.hunt@oracle.com>
Date: Fri, 11 Jul 2014 12:17:16 -0700
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <E7E6E80A-0C22-4614-B317-FE3678EA2780@oracle.com>
To: Martin Thomson <martin.thomson@gmail.com>

The TLS issue is certainly a big part of the problem. The perception is that TLS now needs to terminate at the service provider cluster node rather than the load-balancer because end-to-end encryption, in-the-data-center-encryption requirements, and/or web proof-of-possession issues arising from the authentication header.

From the TLS perspective, if TLS must terminate at the service provider node than the load-balancer is now in the same position with the same challenges as any client side proxy.

It is not clear to me yet, whether this is something that is facilitated in HTTP/2 connection handling, or TLS or both.

It would be helpful to discuss the load-balancer scenario as it is a MITM proxy and from there we can figure out what elements of HTTP or TLS are in play.

At least on the surface, having read the proxy problem draft, I found many of the issues/patterns to be quite similar and thoughtful.



On Jul 11, 2014, at 11:54 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 11 July 2014 11:40, Phil Hunt <phil.hunt@oracle.com> wrote:
>> Any reason why load-balancers arenít in this discussion?  With more end-to-end security coming in place, load balancers are starting to have similar or even more complex challenges.
> The focus so far has been on the role of proxies on the client side.
> The important issue being the role that an external third party (in
> the figurative sense) has in what is - at it's core - a two-party
> conversation.  Of course, that is a gross oversimplification of the
> matter and doesn't do justice to the vast range of options possible in
> this space.
> Load-balancers (or gateways) are usually part of the first two
> parties; they are able to assert an authenticated identity as a
> server.  That means that the issues are quite different.
> There are the TLS issues arising from this (key management,
> interaction with the handshake, etc...), which have been the subject
> of extensive discussion in TLS.  Those discussions are more
> appropriate in that forum.
> Then there are the intermediation concerns at the HTTP layer.  We have
> had a lot of discussion about the details of the protocol design for
> gateways.  It might even be said that the conversation - certainly
> recently - has been dominated by these concerns.
> Is there a specific aspect of the conversation that you would like to
> see us cover more thoroughly?
Received on Friday, 11 July 2014 19:17:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC