Re: [TLS] Proposed text for removing renegotiation

[Martin Thomson <[e-mail]>]

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.

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.

Then there's the use of renego for HTTP, but we've discussed that
already and the tentative plan is to push on HTTPbis to come up with a
solution that doesn't depend on TLS.  Failing that, or in the event
that we discover other users of spontaneous client authentication, we
will build something into TLS.  That will probably be something
lightweight that doesn't cause the sorts of issues Martin (R) doesn't
think are worth worrying about.

>> The current and pending states for both read and write
>> direction are integral parts of the spec.
>
>I don't think documenting/managing those states would be integral at all if we didn't need to support rekeying.

That's right.  That's a presentation consideration, as alluded to
above.  As much as possible, I tried to make them non-integral in my
proposed text.