Re: [TLS] Proposed text for removing renegotiation

[Brian Smith <[e-mail]>]

On Wed, May 28, 2014 at 1:05 PM, Salz, Rich <[e-mail]> wrote:

> Ø  The advantage with this is that only the applications that need to
> deal with this problem are impacted by it.
>
> Strongly disagree.  This requires applications to know way to much about
> the TLS layer:  what cipher is being used, how SSL is packing things into
> records, and how often a cipher needs to be “reset” and what that entails.
>

The application would only have to be aware that the connection may at some
point become unusable because the TLS implementation did something like
simulating a RST when some crypto limit is reached. Applications that are
exchanging more than 2^32 records per connection already have to cope
somehow with these long-lived connections being reset below the TLS layer.

And/or such applications could choose to use cipher suites that aren't
limited to 2^32 records. I have just re-read SP-800-38D section 8.3 which
sets the limit on the number of invocations of AES-GCM with a given key.
SP-800-38D doesn't actually limit AES-GCM to 2^32 invocations as long as
the deterministic construction is used and as long as the invocation field
is larger than 32 bits, if I am reading it correctly. The birthday attack
issue on the 64-bit invocation field used in AES-GCM cipher suites could be
mitigated by tightening the requirements for AES-GCM in TLS 1.3 and/or by
defining new AES-GCM cipher suites that are required to have IVs generated
using the deterministic construction with large(r) invocation fields.

And/or, implementations that send/receive large amounts of data on a single
connection could tune their TLS stacks so that they will never (or almost
never) get close to whatever limit the cipher suite has.

And/or the TLS implementation could optionally provide some kind of simple
notification mechanism to tell the application that the connection will
become unusable "soon," so that an application could start a new
connection/session before the old one stops working, to minimize the
performance impact.

Cheers,
Brian

[1] http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf(section
8.3)