Re: Client Certificates - re-opening discussion

["[e-mail]" <[e-mail]>]

First I am really thankful for this discussion as  I had not been able
to understand what exactly the problem with client certs and 
HTTP/2.0 were. This is very helpful.

> On 21 Sep 2015, at 07:09, Yoav Nir <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> 
>> On Sep 21, 2015, at 6:30 AM, Mike Bishop <[e-mail] <mailto:[e-mail]>> 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.

This seems to show that this is not a client certificate problem but another problem.

In a data driven web, where the client generates the page in Single Pages apps (SPA), the 
identifying  information about the user would be in a seperate resource. As that information 
became available to the SPA would redraw itself, to take that into account.

The way you state the problem it seems to be related to a resource being both public
and protected simultaneously, with the protected version of the resource returning more 
information than the public one. How would a web server indicate to the client that
it should re-download certain resources that now contain more information? Is this even
good practice?  Those are interesting questions.

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

makes sense to me.

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



Social Web Architect
http://bblfish.net/