Re: [TLS] Followup on Update

[Eric Rescorla <[e-mail]>]

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:
> > Folks,
> >
> > I'd like to get a sense of the WG on whether they want to pursue the
> Update
> > mechanism [0].
> >
> > There are several possibilities here, including:
> >
> > - Just do basic Update
> > - Move session ticket establishment to Update
> > - Mode client authentication to Update
> >
> > My sense from the discussion in HNL was that people were generally
> > positive on basic Update and unsure on the other two. If that's right,
> > I'll buff up PR#94 for merge into the spec (pending chair approval).
> >
> > Thanks,
> > -Ekr
> >
> >
> > [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.

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.



> 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?



> 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.

-Ekr