Re: [TLS] Proposed text for removing renegotiation

[Hubert Kario <[e-mail]>]

----- Original Message -----
> From: "Martin Thomson" <[e-mail]>
> To: "Geoffrey Keating" <[e-mail]>
> Cc: [e-mail]
> Sent: Thursday, May 29, 2014 12:45:18 AM
> Subject: Re: [TLS] Proposed text for removing renegotiation
> 
> On 28 May 2014 15:25, Geoffrey Keating <[e-mail]> wrote:
> > I think this should be handled by TLS, not by having the application
> > request rekeying or renegotiation.  If TLS handles it, I don't see why
> > there's a need for a special 'renegotiate' or 'change key' message; it
> > can quietly change the key when the appropriate limit is hit.
> 
> I wasn't proposing that the application be in control of when rekeying
> occurs.  (Yes, if an app needs an explicit break in continuity, then
> opening a new connection is a perfectly reasonable way to achieve that
> goal.)
> 
> Yes, you could just roll on through, identify a point where rekeying
> is necessary and automatically do it.  That's even more aggressively
> spartan than what I've proposed.
> 
> A message enables more than just necessary rekeying.  It also allows
> for read and write states to be kept in sync.
> 
> It also means that you don't have to go to great lengths to contrive a
> rekeying scenario in your testing.  I certainly don't want rekeying to
> be rare enough that it breaks the first time that it ever actually
> happens.  That's a surefire plan for backup generator syndrome.

Transferring 64GB of data with TLS over loopback on a relatively modern
machine (even without AES-NI) takes less than an hour. I wouldn't
call it going to great lengths to test.

-- 
Regards,
Hubert Kario