|From:||Damir Simunic <damir(dot)simunic(at)wa-research(dot)ch>|
|To:||Craig Ringer <craig(at)2ndquadrant(dot)com>|
|Cc:||Jacob Champion <pchampion(at)pivotal(dot)io>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Proposal: http2 wire format|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> On 26 Mar 2018, at 12:47, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 26 March 2018 at 17:34, Damir Simunic <damir(dot)simunic(at)wa-research(dot)ch> wrote:
> > As you move forward with the PoC, consider: even if you decide not to
> > become protocol-layer experts, you'll still need to become familiar
> > with application-layer security in HTTP.
> Good point. Application layer security is indeed a concern.
> h2 has provisions for security by design, and a significant amount of research going into this on a large scale. Adopting h2 instead of inventing our own v4 gets us all this research for free.
> HTTP2, please, not "h2".
> It looks HTTP2 does use the term "h2" to mean "http2 over TLS", to differentiate it from "h2c" which is HTTP2-over-cleartext.
> IMO, you'd have to support both. Mandating TLS is going to be a non-starter for sites that use loopback connections or virtual switches on VMs, VLAN isolation, or other features to render traffic largely unsniffable. They won't want to pay the price for crypto on all traffic. So this needs to be "HTTP2 support" not "HTTP2/TLS (h2) support" anyway.
Makes sense; I’ll update all wording and function names, etc. No difference to the substance of this proposal. The same code path handles both h2 and h2c. TLS is optional, a matter of detecting the first byte of the request and taking the appropriate action.
I think we can reliably and efficiently detect h2, h2c, and FEBE requests. Of course, the behavior needs to be configurable: which protocols to enable, and how to resolve the negotiation. In my mind this is self-evident.
> Re Pg and security: By and large we don't invent our own security protocols. We've adopted standard mechanisms like GSSAPI and SCRAM, and vendor ones like SSPI. Some of the details of how they're implemented in the protocol are of course protocol specific (and thus, opportunities for bugs/design mistakes), of course.
> But you will get _nowhere_ in making this a new default protocol if you just try to treat those as outdated and uninteresting.
Agreed: new default protocol must be covering 100% of existing use cases, _and_ add more compelling capabilities on top.
If anything I wrote made it appear contrary to that goal, it is purely because of my current focus on getting to a PoC.
> In fact, part of extensibility considerations should be extensible authentication.
> Authentication and authorization (which any new protocol really should separate) are crucial features, and there's no one-size-fits-all answer.
I think that HTTP2 gets us much closer to that goal. My vision is to enable application-developer-defined authentication and/or authorization as well. This is something to research once the framing is in place.
> If you just assume, say, that everything happens over TLS with password auth or x.509 client certs, you'll create a giant mess for all the sites that use Kerberos or SSPI.
100% agreed on everything you say, and thanks for taking the time to write this up.
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
|Next Message||Damir Simunic||2018-03-26 11:11:02||Re: Proposal: http2 wire format|
|Previous Message||Craig Ringer||2018-03-26 10:47:59||Re: Proposal: http2 wire format|