Re: Client Certificates - re-opening discussion

> On Sep 21, 2015, at 6:30 AM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> 
> Better than renegotiation?  Nothing – which is the point.  Renegotiation worked, and our first step is parity with downlevel.

So if this working group rejected renegotiation (which worked), why would this new mechanism be acceptable?

> 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.

That’s a good thing, but IMO it doesn’t matter to httpbis.

> 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.

Having the application layer stall doesn’t help. The client requests resources A, B, and C. Resource B requires client authentication. By the time the application stalls, waiting for the client authentication, resources A and C may not have been noticed, or the requests may have been serviced, with A and C in a buffer waiting to be encrypted, or the requests may have been serviced and encrypted and on the way back to the client. A and C may be received in the authenticated or the non-authenticated context. Imagine, for example, that A is a bit of HTML that says “Hello, guest” in the unauthenticated context, or “Hello, Mike” after authentication. You can get the certificate picker and still see the “Hello, guest” on the page.

What’s more, I think HTTP authentication has the same issue. If one request gets processed and generates a 401 with WWW-Authenticate, other resources may or may not have been serviced. You can fix this by carefully designing the application so that you don’t load resources that are different based on state at the same time as the authentication is going on.

> 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.

Does it matter for the client?

Yoav