Re: [TLS] Followup on Update

[Dave Garrett <[e-mail]>]

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.

> 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