Re: [TLS] Followup on Update

[Dave Garrett <[e-mail]>]

On Thursday, March 05, 2015 02:40:28 pm Eric Rescorla wrote:
> On Tue, Feb 24, 2015 at 9:09 PM, Dave Garrett <[e-mail]>
> wrote:
> > On Tuesday, February 24, 2015 09:00:46 pm Eric Rescorla wrote:
> > > On Tue, Feb 24, 2015 at 5:43 PM, Dave Garrett <[e-mail]>
> > > wrote:
> > > > On Tuesday, February 24, 2015 07:44:22 pm Eric Rescorla wrote:
> > > > > [0] See https://github.com/tlswg/tls13-spec/pull/94 for a WIP
> > > > > version of the basic mechanism.
> > > >
> > > > The current proposal says:
> > > >
> > > > "An implementation MAY send an UpdateRekey at any time after
> > > > the handshake completes."
> > > >
> > > > Is there a particular reason to not just have an automatic rekey at
> > > > semi-regular intervals? So, every N records or M minutes (or whichever
> > > > comes first) an endpoint must send a rekey, and then after a similarly
> > > > measured interval the other endpoint sends a rekey; repeat ad
> > > > infinitum.
> > >
> > > It's not entirely clear that we know how to design a good heuristic here,
> > > especially one that covers the entire range of possible algorithms.
> >
> > That's sort of my point; this proposal requires implementations to do so.
> > I'm saying that picking one in the spec would be preferable to leaving it
> > up to the whims of whatever the many combinations of implementations
> > end up deciding. Even if some use-case needs to add rekeys, starting
> > from a conservative heuristic in the spec would ensure implementations
> > are provided with at least a general expectation of how to use this.
> 
> I'm going to argue that the frequency of update is a semi-orthogonal issue.
> I.e., if you think this mechanism works, then we can decide to put it in
> and have a separate discussion of minimum update frequency.

No objection.

A baseline, minimum, and maximum frequency are all needed here, plus recommendations on why to diverge from baseline and what to do if limits are exceeded. A new fatal alert for passing limits sounds appropriate. Without ~something~ specific, however, this sounds like trouble.

On a somewhat separate issue, I think there needs to be something indicating when an "ignored" ACK message is appropriate and how to deal with it properly at both endpoints.

The gist of my concern is that this needs to all be spelled out very carefully with strong expectations. It needs to be very clear to prohibit rarely or never rekeying or a million rekeys in one second and with a specification on how to react to things. As many have pointed out, leaving things vague and up to implementations eventually causes problems that may never be fixed.


Dave