Re: [TLS] Proposed text for removing renegotiation

[Geoffrey Keating <[e-mail]>]

Martin Thomson <[e-mail]> writes:

> On 27 May 2014 22:47, Brian Smith <[e-mail]> wrote:
> >> It's not possible to just remove renegotiation.
> >
> >
> > Why not? What is the motivation for keeping any form of renegotiation, even
> > rekeying? It isn't clear from the public mailing list discussions what is
> > motivating the rekeying feature. (Perhaps I overlooked something; if so, a
> > link to the past decision on this would be appreciated.)
> 
> That statement was merely referring to the fact that there are other
> considerations that removing renegotiation exposes:
> 
> AES-GCM (for example) can't be used with the same key indefinitely.
> 2^32 records is the limit apparently.  We have reports of services
> that use the same connection for up to months with high volumes of
> traffic.  Over that period, the sequence number might roll over, even
> if the keys are still good.  Rekeying allows for those uses.

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.

For sequence numbers, rollover also should (indeed must) be handled by
DTLS.  There are many possibilities, but the easiest is that if we're
removing renegotiation, so the cipher state can change at most once,
so in DTLS we can remove the epoch counter and make the sequence
number 64-bit, and say that if the 64-bit counter is exceeded (will
probably never happen) it is an error and the connection should close.

> It also provides a measure of forward security in that old keys can be
> thrown away.  A break of a server only allows the attacker to gain the
> plaintext of a connection back to the last rekeying event.

This definitely seems like a case where you want to close the
connection and open a new one, directed by the application.