Re: Client Certificates - re-opening discussion

[Eric Rescorla <[e-mail]>]

On Sat, Sep 19, 2015 at 12:18 AM, Stefan Eissing <
[e-mail]> wrote:

>
> > Am 18.09.2015 um 22:57 schrieb Ilari Liusvaara <
> [e-mail]>:
> >
> >> On Fri, Sep 18, 2015 at 01:48:50PM -0700, Eric Rescorla wrote:
> >>> On Fri, Sep 18, 2015 at 10:05 AM, Mark Nottingham <[e-mail]>
> 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