Re: [TLS] Proposed text for removing renegotiation

[Andrei Popov <[e-mail]>]

> 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.
I can't help noticing that this seems to directly contradict the #1 item on the HTTPbis WG charter:
" The Working Group's specification deliverables are:
 * A document (or set of documents) that is SUITABLE TO SUPERCEDE RFC 2616 as
 the definition of HTTP/1.1 and move RFC 2817 to Historic status"
But I guess this is up to the HTTPbis WG to discuss:)

> https://github.com/http2/http2-spec/pull/514/files#diff-8894168382f6487e5e38c4306e613a88R3430 
There are at least two protocol layering violations in this text, which I think will cause problems:
1) Preventing the use of renegotiation in response to a request for a specific protected resource, and
2) Constraining the TLS cipher suites to be used with HTTP/2.

-----Original Message-----
From: Martin Thomson [mailto:[e-mail]] 
Sent: Wednesday, June 11, 2014 1:02 PM
To: Andrei Popov
Cc: Nikos Mavrogiannopoulos; [e-mail]
Subject: Re: [TLS] Proposed text for removing renegotiation

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.