Re: Proposal: http2 wire format - Mailing list pgsql-hackers

> On 26 Mar 2018, at 12:47, Craig Ringer <craig@2ndquadrant.com> wrote:
>
> On 26 March 2018 at 17:34, Damir Simunic <damir.simunic@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.
Adoptingh2 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
orvirtual switches on VMs, VLAN isolation, or other features to render traffic largely unsniffable. They won't want to
paythe 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
codepath handles both h2 and h2c. TLS is optional, a matter of detecting the first byte of the request and taking the
appropriateaction.  

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
GSSAPIand SCRAM, and vendor ones like SSPI. Some of the details of how they're implemented in the protocol are of
courseprotocol 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-allanswer. 
>

I think that HTTP2 gets us much closer to that goal. My vision is to enable application-developer-defined
authenticationand/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
giantmess 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