Re: [TLS] Data limit for GCM under a given key.

On Fri, Nov 6, 2015 at 7:46 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:

>
> > On 7 Nov 2015, at 11:39 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
> >
> > On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote:
> >> Update: we discussed this extensively in Yokohama and based on Watson's
> >> feedback and offline comments from David McGrew, the consensus was that
> we
> >> needed to add some sort of rekeying mechanism to support long-lived
> flows.
> >> Expect a PR on this next week.
> >>
> >> Note: We'll still need guidance to implementations on when to re-key,
> but
> >> we don't expect to have a hard protocol limit.
> >
> > If re-keying is back up for discussion, let me restate my request for it
> to be routine, rather than only an niche-case feature. Any re-key schedule
> should be considered valid, but the spec should set a "SHOULD"-level
> requirement that the minimum be once every N hours or M terabytes,
> whichever comes first (where N & M are some bike-shedable numbers with some
> expectation of randomization in values for each period).
>
> N and M will be different depending on the algorithms, no?
>
> I think before we start with pull requests we should be certain of what
> the requirements are for this rekeying.
>

These were discussed extensively both in the interim and at IETF. The
purpose of rekeying in this context is to deal with cryptographic
exhaustion, namely having more ciphertext under the same key than is safe
for a
given algorithm (where safe is defined by an analysis like the one Watson
has posted upthread).

> Are we OK with just generating new keys from the same internal state (so
> the handshake message is pretty much only “rekey now”),

I believe this is what we agreed both in Seattle and in Prague.

-Ekr

> or
> Do we want freshness (usually in the form of new mutual nonces, or
> Do we want forward secrecy so another diffie-hellamn exchange?
>
> Yoav
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>