Re: Client certificates in HTTP/2

> On Jun 9, 2015, at 8:51 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> 
> There have been a number of suggestions for this scenario, and none of them are entirely satisfying.

To me the “No soup for you!” approach is considerably less satisfying than any of them.

> The TLS WG, last I heard, was discussing a way to present client certificates without full-blown renegotiation.  I'm not sure how the mechanics of that have progressed, if at all, but depending on the form, that might solve this discussion for TLS 1.3.  It doesn't help TLS 1.2, however, where HTTP/2 imposes a restriction on renegotiation.

TLS 1.3 may allow the client to present a certificate without being prompted by the server. That still requires the client to foresee the need for sending a particular certificate. The user interaction would still be weird if you only want to browse the public parts of a website or if you haven’t plugged in your dongle or if you have your key store configured to require a passphrase to use the certificate. What TLS 1.3 will offer is equivalent to Martin’s draft-thomson-tls-care. It’s not enough by itself.

> Our implementation supports two different approaches:  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.  If the server also supports that extension, they can renegotiate as they have always done and exchange certs.  (Our client will only advertise that if it has the cert ready, to minimize the stall introduced to other streams by the reneg exchange.  Cert selection can involve showing UI, and we don't want to stall the network on the user.)  If the client doesn't offer that extension, we'll send HTTP_1_1_REQUIRED and drop the client back to HTTP/1.1, where we'll renegotiate to get the client cert.  Definitely not ideal, but it's the only fully-standardized approach that exists right now.

That’s the “No soup for you” approach. I also question whether you can standardize the TLS_RENEG_PERMITTED extension, because this WG went out of its way to prohibit this behavior, and the reason was IIRC that it led to a race condition between the authentication and the multiple parallel streams. That’s not helped by the client announcing that it has a certificate.

> Martin's approach, along with the early-renegotiation dance in the HTTP/2 spec, still forces the creation of a new TLS connection, something we'd prefer to avoid.  It's better than HTTP_1_1_REQUIRED in that it lets the client keep using HTTP/2, but worse in that it mixes the TLS and HTTP layers, something we'd also prefer to minimize.

While I agree that creation of new TLS streams is something you would want to minimize, the use cases for client certificate are such that this happens seldom. Certificate are used in SSL VPNs, a few high-value websites like some banks (most of them use other methods), corporate portals. These are things the average user would need either a few times a month or a few times a day. As for mixing layers, it’s no worse than an HTTP resource request triggering a TLS renegotiation with different parameters.

Yoav

Received on Tuesday, 9 June 2015 19:43:52 UTC