RE: Client certificates in HTTP/2

We don't have a client cert much of the time.  Two flows exist:

a)  The app above us (above WinInet) knows it needs to supply a client cert.  It sets one on the request, but obviously we can't send it until the server requests it.  We turn on the setting at that point, in anticipation of the server wanting it.

b)  The HTTP/2 server sent us back to HTTP/1.1, and we renegotiated there without stalling anything.  We now have a client cert in memory for that origin, so we'll send the setting on the still-open HTTP/2 connection and try to keep using that connection for future requests.  (Guessing that the client cert is why we got the fallback command for the first request.)  If we get the fallback for more requests, we'll drop the HTTP/2 connection.

As to your last comment, I wholeheartedly agree.  This should have been left in the realm of TLS, where the server can challenge for client auth at any time -- which would mean not prohibiting reneg in an HTTP spec.  But that ship has sailed, and now we all get to find our ways around or through that.

-----Original Message-----
From: Adrien de Croy [mailto:adrien@qbik.com] 
Sent: Tuesday, June 9, 2015 2:35 PM
To: Mike Bishop; Yoav Nir; HTTP Working Group
Subject: Re: Client certificates in HTTP/2



------ Original Message ------
From: "Mike Bishop" <Michael.Bishop@microsoft.com>
To: "Yoav Nir" <ynir.ietf@gmail.com>; "HTTP Working Group" 
<ietf-http-wg@w3.org>
Sent: 10/06/2015 5:51:39 a.m.
Subject: RE: Client certificates in HTTP/2

<snip>

>
>A client which has a client cert ready to offer will send an extension 
>setting TLS_RENEG_PERMITTED advertising that it's willing to accept a 
>server-initiated renegotiation.
>
I don't really like this approach.  When would the client send this option?

a) always -> let's tell every site we have a client cert
b) only on sites where the client previously received a request for a cert -> yay another database to maintain
c) after some strange UI (open this link with client cert)
d) by magic

What's wrong with being challenged for a client cert, it's just like being challenged for auth, we're not proposing deprecating 403 are we?

Some sites may wish to make it conditional whether a client cert is required based on other things.  This requirement to pre-advertise support just seems like bad engineering when TLS already has a mechanism to deal with client certs


Adrien

Received on Tuesday, 9 June 2015 22:56:20 UTC