Re: [TLS] Call for Consensus on removal of renegotiation

[Yoav Nir <[e-mail]>]

On Jun 25, 2014, at 11:52 PM, Salz, Rich <[e-mail]> wrote:

>> If that application ever ran enough traffic that renegotiation for rekeying was
>> needed, upgrading to the next OpenSSL that includes TLS 1.3 would not be as
>> smooth.
> 
> Unless that next OpenSSL knew enough to do the re-key work. Hm. This would argue that Martin's approach is probably less disruptive than my preferred approach.

Even if OpenSSL knows enough to start a new connection, the application needs to be able to bind the old connection to the new, unless we add some kind of session management to TLS. But that would trade new complexity for old complexity, so I don’t think we want that.


>> BTW: This discussion is totally missing the other use of renegotiation - to
>> move from server-authenticated to mutually-authenticated. Unless that
>> need is addressed (by some mechanism), I can't support removing
>> renegotiation.
> 
> I believe the consensus is to adopt http://datatracker.ietf.org/doc/draft-thomson-tls-care/ which I prefer to think of as "do have any idea who I am”

I must have missed when they called consensus on that. In that case, I’m with the “remove it entirely (1)” camp. We use 128-bit ciphers today. Even with CBC, you will replace the client and the server long before you’ve encrypted so much that you need to rekey.  Periodic rekeying is something that auditors like, but is very rarely needed in HTTPS, SMTP and the like. I’m fine with forcing the few applications that need to to adapt.

Yoav