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

Re: TLS renegotiation

From: Brian Smith <brian@briansmith.org>
Date: Tue, 28 Jan 2014 13:37:25 -0800
Message-ID: <CAFewVt5QBz9pRgW7vMyL82pdPMn1_dh1EHFXMhww-_h5ZQf+QQ@mail.gmail.com>
To: Mike Belshe <mike@belshe.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Sat, Jan 25, 2014 at 5:01 AM, Mike Belshe <mike@belshe.com> wrote:
> On the good news side, almost nobody uses client auth or renegotiation.
> This is in part due to the fact that it just doesn't work well with any
> protocol, HTTP/1 or otherwise.

With that in mind, here's a strawman:

1. When "h2" has been negotiated (through ALPN/NPN/whatever), then TLS
renegotiation MUST NOT be done on the connection.

This would mean that if HTTP/2 is negotiated during the initial
handshake then TLS renegotiation will never happen on the connection,
and if HTTP/2 is negotiated during a renegotiation then no more
renegotiation handshakes will be done.

2. If the server negotiates the protocol "h2r" then the client MUST
immediately initiate a renegotiation, offering only the "h2" protocol,
the client must wait for the renegotiation once it receives the
hello_request, and the client MUST NOT send any application data or do
any coalescing until the renegotiation handshake has completed.

3. Clients that offer the "h2" protocol during the initial handshake
and that support TLS renegotiation for HTTP/1 connections SHOULD offer
the "h2r" protocol during the initial handshake. Clients that do not
support renegotiation MUST NOT offer the "h2r" protocol.

The effect would be that there may only be one renegotiation on a
HTTP/2 connection and that renegotiation must happen at the very
beginning of the handshake, before any coalescing has been done and
before any data has been sent.

Note that "h2r" would implicitly disable False Start.

The main advantage of this proposal is that it provides a way for
servers that require client certificate authentication to work with
HTTP/2, increasing backward compatibility. The secondary advantage of
this proposal is that it prevents the issues that clients currently
have of mapping requests/responses to client and/or server
certificates. The primary disadvantage of this proposal is that it
requires the application to be more aware of renegotiations than it
previously was.

Unlike the "http-tls-relaxed" option negotiation that I objected to
before, the "h2r" option for negotiating renegotiation doesn't
disclose any security-sensitive information, unless knowing that the
client supports renegotiation or not is security-sensitive. AFAICT, it
is an additional fingerprinting risk but it isn't otherwise
security-sensitive assuming a correct and secure implementation of
renegotiation by both parties (a big assumption).

Received on Tuesday, 28 January 2014 21:37:52 UTC

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