W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: TLS renegotiation

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>
Message-ID: <20140129185553.GA24310@LK-Perkele-VII>
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

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

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

Received on Wednesday, 29 January 2014 18:56:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC