Re: [TLS] Renegotiation: trying to summarize

This is a good summary, thanks Martin. It also seems that #1 and #2 break (or significantly complicate) existing TLS client auth scenarios, while #3 and #4 allow these client auth scenarios.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Thursday, June 19, 2014 3:44 PM
To: tls@ietf.org
Subject: [TLS] Renegotiation: trying to summarize

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.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls