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

How is this significantly different for HTTP/2 than from HTTP/1.1 with TLS ?
Or are you just generally raising this as an issue?

In the former case, you're at least guaranteed to have the TLS SNI header
which helps load balancers substantially in this case.  (Quite a bit of the
TLS 1.3
discussion on client_hello encryption has been on how load balancers can
still
route traffic without needing to be able to obtain access to secrets only
on the service
provider node.)

         Erik



On Fri, Jul 11, 2014 at 3:17 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

> Martin,
>
> 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.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
> 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?
> >
>
>
>