Re: [TLS] Followup on Update

[Eric Rescorla <[e-mail]>]

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.

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
>