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

Re: TLS renegotiation

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 29 Jan 2014 09:41:18 -0800
Message-ID: <CABkgnnXvSB-jp_pRuNhwXNMDRFPYo9x493s0uXvYco5r5Gykdw@mail.gmail.com>
To: Yoav Nir <synp71@live.com>
Cc: "Ludin, Stephen" <sludin@akamai.com>, Mike Belshe <mike@belshe.com>, HTTP Working Group <ietf-http-wg@w3.org>
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.

I expected to hear something like this.

Now.  The challenge for those people is to articulate what
restrictions are acceptable.

Preventing application protocol changes as a result of renegotiation
seems reasonable; and we have an
http://http2.github.io/http2-spec/#INADEQUATE_SECURITY now that can be
used if any other property degrades as a result of renego.  And
obviously, neither peer needs to accept an attempt at renegotiation.
Is that enough?

About the connection coalescing feature that has been part of SPDY and
will likely be made formal in HTTP/2 (see #359).  What behaviour do we
expect from a client when a connection is renegotiated?

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.
Received on Wednesday, 29 January 2014 17:41:46 UTC

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