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

[Yoav Nir <[e-mail]>]

On Jun 25, 2014, at 11:26 PM, Colm MacCárthaigh <[e-mail]> wrote:

> On Wed, Jun 25, 2014 at 11:47 AM, Daniel Kahn Gillmor
> <[e-mail]> wrote:
>> If we aren't providing an additional facility for re-keying, then i am
>> not OK with removing renegotiation.  TLS needs a way for high-traffic,
>> longstanding connections to stay up without "dead air" (as i think Sean
>> called it earlier).  So i can't choose (1).
> 
> Probably a stupid and ignorant question; but what prevents
> applications with this kind of requirement from creating a new
> connection, negotiating a new key, and then switching to the new
> connection when they're ready?

Nothing. But that would require changing those applications. 

Before: The client opens a connection, calls the TLS library, and then transmits arbitrarily-much data for an arbitrarily-long time. If so much data has been transmitted that rekeying is warranted, The TLS library will do it transparently to the application.

After: The client opens a connection, calls the TLS library, and then transmits information. After a while, either a data count passes some limit, or a timer expires, and the application is informed by the TLS library that this connection can no longer be used. So the client opens a new connection and calls the TLS library again. Simple? Not really, because now we need to add to the application some session mechanism to bind the old and the new connections. Think telnet-over-ssl as an alternative to SSH. You don’t want to lose your environment and what you were just typing, right? This is a requirement from the application that didn’t exist before.