RE: Client Certificates - re-opening discussion

Kind of a non-problem, but it’s also the problem itself.  The HTTP layer will call different APIs in TLS, but the API HTTP exposes (get client certificate) won’t necessarily change.

·        HTTP/1.x + TLS <=1.2 – Client certs work via renegotiation

·        HTTP/x + TLS 1.3 – Client certs work via new TLS feature that isn’t renegotiation

·        HTTP/2 + TLS 1.2 – How do client certs work?

It’s a time-scoped problem, since we hope everyone will eventually be on TLS 1.3, but it’s a nearly-universal problem at the moment.  There are many proposed kludges for HTTP/2 over TLS 1.2 in the meantime, but we need to find something with broader support than any idea currently has.

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Saturday, September 19, 2015 11:18 AM
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>; Mark Nottingham <mnot@mnot.net>; Henry Story <henry.story@co-operating.systems>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Client Certificates - re-opening discussion



On Sat, Sep 19, 2015 at 12:18 AM, Stefan Eissing <stefan.eissing@greenbytes.de<mailto:stefan.eissing@greenbytes.de>> wrote:

> Am 18.09.2015 um 22:57 schrieb Ilari Liusvaara <ilari.liusvaara@elisanet.fi<mailto: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<mailto: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.

Well, presently renegotiation is illegal in HTTP/2, so this is a non-problem.

However, I suppose if we land TLS 1.3 PR#209 it will come back.

-Ekr

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