[TLS] Renegotiation: trying to summarize

[Martin Thomson <[e-mail]>]

It's been a long thread, I think a recap is in order.  Here's the
options I've seen thus far:

1. Remove renegotiation entirely

Brian Smith proposed this.  Arguments for are its beautiful simplicity
and the fact that it ensures that you limit the time that a single
session (and the corresponding keys) live.  Arguments against are that
it doesn't allow for long-lived connections; and we've evidence
(thanks David) that suggests that rekeying on very short timescales is
interesting to some TLS users, misguided or not.

2. Remove renegotiation and replace it with a key refresh

This is what I've proposed, though the details could easily be
different (e.g., you could do a new DH exchange for maximal PFS, or
you could invent a new message type).  The advantage over #1 is that
you can have a much longer connection lifetime.  That could equally be
considered a disadvantage.

3. End TLS and use the same L4 for a new session

Here we effectively end TLS, but keep the TCP connection (or
equivalent) around for use in a new TLS session.  In some versions,
this has an "end TLS" message that signals the end of the old session.
In others, starting a new handshake terminates the old session
implicitly.

Some have suggested that it be phrased in API terms as a new
connection, that the application needs to request a new connection to
get the handshake to happen.  In others, this is just a different spin
on renegotiation, with a little dead air while everything is changed
out.  In the latter case, I don't see how this is any different to
retaining renegotiation.  The former seems like an optimization of #1.

4. It ain't broke, don't fix it

The general thread here is that any problems are either fictional, or
the result of problems in the TLS API or the application that uses it.


In short, I think that #1 and #2 suggest that there is a potential
problem if session properties can change; #3 and #4 reject that
thesis.

You could treat the 1&2 vs. 3&4 as the high order bit.  Then, you
either choose to limit the lifetime of sessions (#1) or go long (#2).
Alternatively, you decide whether to break sessions apart (#3) or keep
the old renegotiation scheme (#4).  On the other hand, 3 could looks a
lot like an optimization of #1, though it might suggest the potential
to get things wrong.