- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Wed, 29 Jan 2014 20:55:53 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Yoav Nir <synp71@live.com>, "Ludin, Stephen" <sludin@akamai.com>, Mike Belshe <mike@belshe.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Jan 29, 2014 at 09:41:18AM -0800, Martin Thomson wrote: > On 29 January 2014 00:57, Yoav Nir <synp71@live.com> wrote: > > I know it’s not popular in content and social networking, but client > > authentication does have its uses, and often cannot be done sanely (with > > existing protocols) without renegotiation. > > The first cost that I'm aware of with respect to client certificates > is that if a server that might be the target of coalescing it will be > unable to have separate client authentication for the different > domains that could be coalesced. > Here are my thoughts on this: Renegotiating to change client certificates makes me feel uneasy (the "I feel that there will likely be issues here but I'm not sure what those are" feeling). Two ways to do client certificates without renegotiation: 1) Signal certificate requirements using HTTP Part7 authentication and have client establish a new connection (and then decide what to do with the existing one, perhaps keep it around for coalesced requests). -> Simple bit inefficient. Also works with HTTP/1.1. 2) Have a way to attach certificate to existing HTTPS connection, with a way to signal the certificate to use on request. This is highly nontrivial[1]. SPDY3 had such feature (the CREDENTIALS frame)[2]. -> Hairy but efficient. HTTP/2.0 specific. [1] In the few homebrew crypto protocols I have done, binding authentication has been the biggest source of security problems (of the "bad crypto" kind not "implementation bugs" kind) that I know of. [2] SPDY3 CREDENTIALS reminds me of one of my homebrew crypto stuff... Before it was security-patched... -Ilari
Received on Wednesday, 29 January 2014 18:56:18 UTC