RE: Client Certificates - re-opening discussion

Better than renegotiation?  Nothing – which is the point.  Renegotiation worked, and our first step is parity with downlevel.  Renegotiation, however, attempted to bring many functions together, some of which made the TLS WG uncomfortable.  This PR creates a more scoped feature targeted at only the presentation of client credentials to the server, which is the feature we actually need.

It sounds like, in part, we have different understandings of why renegotiation was prohibited in the first place.  You argue it was prohibited because there’s some inherent indeterminacy, particularly if the application layer doesn’t stall.  I’d argue that that indeterminacy can and should be handled by the application that knows what resources care about the client’s identity and which don’t.

If multiple requests cause the server application to query the HTTP layer for the client’s certificate, then all those requests will wait until the client authentication has completed, just as they would have on a non-multiplexed connection.  Where multiplexing adds a new wrinkle is that, under HTTP/1.1, those connections that didn’t require authentication would proceed without interruption until they’re used for a protected request.

Perhaps the fundamental question is, when does the client need to know that the server had seen the certificate prior to generating the response?  In HTTP/1.1 over TLS 1.x, it could know that the server had seen it, but couldn’t know whether the server cared.

From: Yoav Nir [mailto:ynir.ietf@gmail.com]
Sent: Sunday, September 20, 2015 2:49 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Eric Rescorla <ekr@rtfm.com>; Stefan Eissing <stefan.eissing@greenbytes.de>; 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

Hi, Mike

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