W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

Re: Client Certificates - re-opening discussion

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 23 Sep 2015 10:09:51 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <E549D977-DC88-4E39-B65B-EE674E541157@mnot.net>
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Stefan,

> On 22 Sep 2015, at 7:08 pm, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
> 
> 
>> Am 21.09.2015 um 20:23 schrieb Mike Bishop <Michael.Bishop@microsoft.com>:
>> 
>> I have no issue with defining something at the application layer that becomes a viable alternative to move toward.  In the meantime, though, we want a way for applications built on the old/current model to use HTTP/2.
> 
> Thanks, Mike. My feelings exactly.
> 
> We want sites to enable HTTP/2. We do not want them to crash and go down in flames, because the existing HTTP/1 config was not suitable. We'd like predictable (or at least defined) behaviour of clients when running into whatever the server sends back in such scenarios.
> 
> 
> In order to completely avoid renegotiations on HTTP/2 (and I think we all agree on that), one approach would be to force the client back to HTTP/1.1 using another (new or open) connection. The response should indicate the realm where this restriction applies.
> 
> Note that servers may be unable to trigger client certs on connection setup. This often happens on the first request, triggering a renegotiation. Often specific TLS parameters only apply to special locations on a server (in existing configurations - I do not say that this is a good approach).
> 
> This may be done by extending the 421 response with additional headers to indicate the desired behaviour. It would be good to hear from people on the client side what their thoughts about this are.

See:
  http://httpwg.github.io/specs/rfc7540.html#rfc.section.9.2.1
  http://httpwg.github.io/specs/rfc7540.html#HTTP_1_1_REQUIRED

"""
This effectively prevents the use of renegotiation in response to a request for a specific protected resource. A future specification might provide a way to support this use case. Alternatively, a server might use an error (Section 5.4) of type HTTP_1_1_REQUIRED to request the client use a protocol that supports renegotiation.
"""

Cheers,



--
Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 23 September 2015 00:10:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:46 UTC