- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Sat, 19 Sep 2015 09:18:59 +0200
- To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Cc: Eric Rescorla <ekr@rtfm.com>, Mark Nottingham <mnot@mnot.net>, Henry Story <henry.story@co-operating.systems>, HTTP Working Group <ietf-http-wg@w3.org>
> Am 18.09.2015 um 22:57 schrieb Ilari Liusvaara <ilari.liusvaara@elisanet.fi>: > >> On Fri, Sep 18, 2015 at 01:48:50PM -0700, Eric Rescorla wrote: >>> On Fri, Sep 18, 2015 at 10:05 AM, Mark Nottingham <mnot@mnot.net> wrote: >>> >>> Hi Henry, >>> >>> Thanks, but this is a much more narrowly-scoped discussion -- how to make >>> client certs as they currently operate work in HTTP/2. >> >> >> Is this a question about HTTP/2's limitations versus HTTP/1.1 or about >> deficiencies >> in HTTP/1.1 that HTTP/2 has not fixed? > > I think this is about the extra limitations of HTTP/2 regarding client > authentication caused by major design differences between HTTP/1.1 and > HTTP/2. > > Client certs in HTTP/1.1 aren't too great, but at least those don't > seem to even remotely have the same problems as client certs in HTTP/2 > (especially when in web environment). Just to have everyone on the same page. The problems - as we see them in httpd - are 1. http/1.1 requests may trigger client certs which may require renegotiation. Processing is no longer sequential with http/2, causing conflicts. Even if mutexed what does connection state and h2 stream have to say to each other and for how long? 2. connection reuse for different hosts is much more likely as a lot of sites have a long list of subjectAltNames. That raises the likelihood of conflicts as described above. Any advice on how to address this in an interoperable way is appreciated. //Stefan
Received on Saturday, 19 September 2015 07:19:25 UTC