> On 26 Mar 2018, at 12:47, Craig Ringer <cr...@2ndquadrant.com> wrote: > > On 26 March 2018 at 17:34, Damir Simunic <damir.simu...@wa-research.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
