Subject: Re: [TLS] Followup on Update

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Mar 2015 11:40:28 -0800

On Tue, Feb 24, 2015 at 9:09 PM, Dave Garrett <[email-masked]>
wrote:

> On Tuesday, February 24, 2015 09:00:46 pm Eric Rescorla wrote:
> > On Tue, Feb 24, 2015 at 5:43 PM, Dave Garrett <[email-masked]>
> > 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.

Best,
-Ekr

> > As a minor nit, it's kind of a pain to say every M minutes because
> > often TLS stacks are driven by the application and don't have internal
> > timers, but you could of course say "first record after M minutes"
> > which would (probably) be close enough.
>
> I'm not suggesting a precise heuristic here; just some semi-regular
> interval
> that would be more specific than "MAY ... at any time". With it left as
> vague
> as proposed, you could get deployments that never rekey or ones that
> decide to rekey stupidly frequently. (DoS risk if not implemented
> efficiently?) Picking any arbitrary interval would make things simpler and
> ensure that this feature is used sufficiently.
>
> The simplest route is to just specify a number of records to rekey after.
>
> > > This would also ensure entropy for rekeying comes from both endpoints
> > > equally over the course of the connection.
> >
> > Can you explain more about why that's an important consideration?
>
> It's just something that occurs to me with the current proposal. It allows
> for one sided rekeys, whereas the handshake gets randomness in each
> hello from each endpoint. It just strikes me as notably different to rely
> on
> just the one source of entropy here (plus previous).
>
> It's a "huh, interesting" thought not a "oh, that's horrible" thought.
>
> > > I would expect it would be better to not rely on implementations all
> > > designing their own heuristics on when to send rekey updates, and also
> > > would avoid multiple updates being sent at the same time by each
> endpoint
> > > (and the possible pitfalls of doing so)
> >
> > The algorithm in this document is intended to be safe in the case of both
> > simultaneous
> > and (I believe) pipelined updates. I'd be interested in knowing if it's
> not.
>
> Yes, I don't think it's a spec risk. An implementation risk is possible,
> though.
>
> It's a new feature that could end up with a new setting for an admin to
> fiddle with that probably doesn't need to be highly variable to do the job.
> Or put another way, it's a feature that I'm overthinking about the
> possibility
> of implementations overthinking how to use it. ;)
>
>
> Dave
>

---

From: Dave Garrett <[email-masked]>
Date: Thu, 5 Mar 2015 15:22:15 -0500

> 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