Re: [TLS] Proposed text for removing renegotiation

[Brian Smith <[e-mail]>]

On Wed, May 28, 2014 at 9:38 AM, Martin Thomson <[e-mail]>wrote:

> 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.
>

Understood. However, as I implied in my other responses today, I don't
think TLS is the place to support that use case. It is enough for the TLS
implementation to be only responsible for ensuring that we don't use a key
beyond safe limits for its usage. How the application recovers from that
limit being reached can be delegated to the application. The advantage with
this is that only the applications that need to deal with this problem are
impacted by it.


> 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.
>

I understand the idea is that both sides could throw away the old master
secret right away and then nobody would be able to decrypt the traffic
protected by that old master secret. However, the "master secret
advancement" mechanism you proposed is calculated using only the old master
secret plus public nonces, which raises some risk of related-key attacks.
As Martin Rex was saying, the advantage of TLS-1.2-style renegotiation is
that the new master secret is clearly (could be made to be) completely
unrelated to the the previous master secret so that related key attacks
aren't (could be made to not be) an issue.

Thus, while a simpler rekeying mechanism definitely makes the protocol
simpler, we'd be trading a useful cryptographic property for that
simplicity. And, most implementations that would support it would actually
become more complicated by having to support both TLS < 1.3 renegotiation
AND TLS 1.3 rekeying.

Consequently, I still think we should keep trying to get rid of
renegotiation without adding anything new in TLS to replace it.

Cheers,
Brian