RE: Client Certificates - re-opening discussion

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.