Re: Client Certificates - re-opening discussion

Hi, Mike

> On Sep 20, 2015, at 1:10 AM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> 
> 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.

I’m not sure I see how PR #209 solves the issue.

HTTP/2 prohibited renegotiation because HTTP/2 is non-sequential. A bunch of requests may be in process and it is non-deterministic which responses will be generated before, during and after the client authentication. One resource might trigger the renegotiation, but several others might receive different responses based on whether or not the user is authenticated.

Now suppose we replace renegotiation with the mechanism proposed in PR #209. Some resource triggers the TLS layer, but instead of triggering a re-negotiation by sending a HelloRequest, it triggers client certificate authentication by sending a CertificateRequest. This is different in some senses: there is no change to the master secret; the old channel bindings are still valid; session keys are not replaced. I don’t see what difference this makes. The connection still changes from a state where the client is anonymous to a state where the client is authenticated. Requests sent by the client still may have been responded to before, during or after the change of state. 

Maybe I’m missing something, but I don’t see what #209 does that renegotiation did not.

Yoav