RE: Client certificates in HTTP/2

There have been a number of suggestions for this scenario, and none of them are entirely satisfying.

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.

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.

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.

-----Original Message-----
From: Yoav Nir [mailto:ynir.ietf@gmail.com] 
Sent: Tuesday, June 9, 2015 12:58 AM
To: HTTP Working Group
Subject: Client certificates in HTTP/2

Hi

Long time ago there was a long discussion about using client certificates on the web with HTTP/2. Feel free to skip the next paragraph if you remember the issue.

Most of the web does not use client certificates. Websites that do don’t like users to get a certificate picker when they first land on the page. So what they do is protect the site with regular, server-authenticated TLS and have a landing page. On the landing page there’s going to be something clickable that says “login with certificates”. When the user clicks that, it sends a request for some resource (maybe “/loginWithCerts.html”). When the server gets that request, it triggers the TLS layer to re-negotiate, this time with the certificate request message that causes the certificate picker to pop up. This is the way it’s usually done in HTTP/1, but for HTTP/2, section 9.2.1 prohibits this use or renegotiation and hints at future specification that might provide this.

So a year ago Martin Thomson wrote a pair of draft for solving this: one an HTTP authentication scheme that just says, “go away and come back with a certificate”, while the other is a TLS extension that tells the server that the client would like to authenticate:
https://tools.ietf.org/html/draft-thomson-httpbis-catch-00

https://tools.ietf.org/html/draft-thomson-tls-care-00


Neither was adopted, here or at TLS, so currently HTTP/2 is not usable with mutual authentication. Why has this (useful IMO) extension withered on the vine rather than progressed?  If anyone needs help in pushing this along, I’ll be glad to help.

Yoav

Received on Tuesday, 9 June 2015 17:52:07 UTC