Re: Client Certificates - re-opening discussion

I agree that it makes the most sense from the client’s perspective to close the HTTP/2 connection and move entirely to HTTP/1 once the H1R response is received.

It’s kind of sad, because most applications that I’ve seen have just one resource that triggers the renegotiation (ours is called “login_with_certs.html”), and everything else is authorized by the cookie that is set by the response to that request. The HTTP/2 connection could be safely used for everything else on the site.

But there is no way for the browser to know that. And trying each resource with the HTTP/2 connection and optionally moving it to the HTTP/1 connection sounds like a really poor idea.

Yoav


> On Sep 23, 2015, at 6:58 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> 
> I agree, it would have been nice to specify some level of scope on the HTTP_1_1_REQUIRED – but then again, the server code may not even know the scope of resources that trigger it, and fallback to HTTP/1.1 is always permissible.  If we receive H1R for one or more resources, we open a 1.1 connection and retry it/them.  If they succeed on 1.1, we’ll switch entirely to 1.1 for the remainder of that session.  (With some additional implementation-specific stuff around the client-cert case and not wanting to stall renegotiation waiting for UI.)
>  
> From: Martin Thomson [mailto:martin.thomson@gmail.com] 
> Sent: Wednesday, September 23, 2015 8:26 AM
> To: Stefan Eissing <stefan.eissing@greenbytes.de>
> Cc: Mark Nottingham <mnot@mnot.net>; HTTP Working Group <ietf-http-wg@w3.org>
> Subject: Re: Client Certificates - re-opening discussion
>  
> 
> On Sep 23, 2015 1:55 AM, "Stefan Eissing" <stefan.eissing@greenbytes.de <mailto:stefan.eissing@greenbytes.de>> wrote:
> > One could advise a client that HTTP_1_1_REQUIRED indicates that the request uri ref indicates the server realm where this restriction applies. For Apache httpd at least, client cert renegotiation is a directory based configuration.
> 
> The notion that you might infer something about other resources based on some unspecified dissection of a URL and a response seems to fragile to be wise. That suggests something explicit, which leads back to 421.
> 
> > Further, a client thus falling back to HTTP/1.1 to trigger the proper TLS params, *could* try to "Upgrade:" to h2 again on the same request, given that all security requirements are fulfilled. This is outside the spec atm, right?
> 
> Yeah, TLS implies ALPN.
> 
> > (I had already one site with "421 Ping Pong" reported, where the client got a 421, teared down the connection, opened a new one, got a 421 on a later request, teared down again, opened exactly as in the beginning a new one... all this does not match exactly this case, but it shows that there are interop issues lurking.)
> 
> Redirect loops happen too, so I imagine that this can be handled in a catchall.
> 
> The ideal solution is to find ways to address all use cases in HTTP/2. For that, I agree that client authentication in response to a request will be needed.
>