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

Erik,

From my perspective this is neither HTTP/2 or 1.1.  I was just responding to Mark’s draft on proxies.

I commented because of the evolving issue with cloud hosting (where there are multi-tenants behind gateways) and new work happening in the app layer with proof-of-possesion confirmation (OAuth WG) and trying to understand how this will all fit together.

The “gateway” as Mark corrected me, seems to share some qualities and issues as Mark discussed.  

Thanks for the the TLS info. Will look further.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com



On Jul 11, 2014, at 1:27 PM, Erik Nygren <erik@nygren.org> wrote:

> 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?
> >
> 
> 
>