Re: [TLS] Proposed text for removing renegotiation

[Martin Thomson <[e-mail]>]

To establish a bit more context here: the consensus in HTTPbis is to
provide a mechanism whereby servers are able to downgrade to HTTP/1.1
for the purposes of corner cases that are only properly supported by
HTTP/1.1.

Aside from some interesting legacy scenarios, client authentication
was considered a major reason for this feature.  We decided not to
adopt something like the -cant draft at the current time, since the
more generic capability was also needed.

On 11 June 2014 12:37, Andrei Popov <[e-mail]> wrote:
> 1. An existing HTTP/1.1 server cannot take advantage of TLS 1.3 if TLS client auth is required. This is because an existing HTTP/1.1 server is not aware of httpbis-cant.

Correct.  That makes something like -cant a prerequisite of an upgrade
to TLS 1.3 for those servers.

> 2. An HTTP/2 server requires an updated TLS stack with tls-care support in order to perform TLS client auth. This is because HTTP/2 prohibits renegotiation.

This can be worked around.  In fact, the proposed text permits
renegotiation in TLS 1.2 (there is no "earlier" here because we
prohibit the use of earlier versions) prior to starting HTTP/2:

https://github.com/http2/http2-spec/pull/514/files#diff-8894168382f6487e5e38c4306e613a88R3430

(This isn't in the main spec due to a dependency issue, that text
captures the established consensus from the most recent interim
meeting.)

> 3. Even with the updated TLS stack in place, an HTTP/2 server cannot negotiate TLS 1.2 and earlier if TLS client auth is required. This is because TLS 1.2 and earlier would send the client cert in the clear, which is bad for client privacy.

See above workaround.  The cost there is an additional round trip (if
you do false start, that is, it's a lot more without).

> 4. Without renegotiation, TLS client auth requires additional round-trips to establish a new TCP connection.

Correct.