Re: [TLS] Proposed text for removing renegotiation

[Andrei Popov <[e-mail]>]

Thanks Martin for pointing out the updated httpbis-cant I-D on github. It seems to provide the same certificate filtering facilities as the CertificateRequest.

There are other significant problems with the removal of renegotiation from TLS 1.3 (please correct me if I'm missing something):
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.
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.
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.
4. Without renegotiation, TLS client auth requires additional round-trips to establish a new TCP connection.

Perhaps the fundamental problem is that httpbis-cant introduces a client authentication challenge in HTTP that cannot be satisfied at the HTTP layer. This breaks the protocol layering, and causes the types of hard-to-manage dependencies listed above.

Even if httpbis-cant and tls-care both become RFCs, and get commonly implemented, and get widely deployed, I believe that the removal of renegotiation from TLS 1.3 creates more problems than it solves.

Cheers,

Andrei

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

On 9 June 2014 11:49, Andrei Popov <[e-mail]> wrote:
>> The former we have decided to solve in HTTP.
>
> Are you referring to these I-Ds:
> http://tools.ietf.org/html/draft-thomson-httpbis-cant-00
> http://tools.ietf.org/html/draft-thomson-tls-care-00
>
> Httpbis-cant talks (rather vaguely) about using "realm" or "other challenge parameters" to select an appropriate client cert. I think client cert selection should be clearly specified before we can say that the mid-session client auth problem has been solved, and remove renegotiation from TLS 1.3.

The selection problem is, as we discussed in Denver, worth addressing.
The short term fix in HTTP/2 will actually be to force these users down to HTTP/1.1.  That's suboptimal, certainly, but it does fix the immediate problem.

As far as the -cant draft goes, I simply haven't uploaded an updated version after our discussion in Denver.  There's a work in progress version on github:
http://martinthomson.github.io/drafts/draft-thomson-httpbis-cant.html

> It would be even better to solve this problem at the TLS layer, so that each application protocol does not need to come up with a separate solution. And avoiding the round-trips involved in establishing a TCP connection would be awesome, too. The current solution using renegotiation has both of these desirable properties.

I'm sympathetic to this, but if HTTP is the only one that wants this particular feature, then we are better off leaving them to work around this.  At least in my opinion.