Re: [TLS] Proposed text for removing renegotiation

Hi Martin,

> 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.

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.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Monday, June 9, 2014 11:17 AM
To: Nikos Mavrogiannopoulos
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed text for removing renegotiation

On 9 June 2014 00:34, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> Could somebody elaborate on what is that issue and why does it need to 
> be solved? (it is not even mentioned in the TLS 1.3 charter) As 
> someone who follows the mailing list that proposal comes out of the 
> blue with no context whatsoever.

I think that this has been covered in the thread, but piecemeal:

* Renegotiation is a major source of security issues, both of the "we screwed the TLS design up" sort and of the "my application didn't realize that these things could change" sort.  There is a clear desire to remove features that enable either sort of problem.

* Renegotiation is just more protocol complexity.  Removing it potentially makes implementations simpler.

I think that either might be sufficient justification for removing the feature.

However, a number of use cases depend on renegotiation to achieve their ends.  Of these, we have identified:

* mid-session client authentication, which uses renegotiation seems to only be used in HTTP

* very long-lived connections, which require renegotiation to re-key occasionally

The former we have decided to solve in HTTP.  As a side note, we just decided to forbid renegotiation in HTTP/2.

The latter can be addressed by my proposal, or any of a number of mechanisms.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls