Re: [TLS] Renegotiation: trying to summarize

[Martin Thomson <[e-mail]>]

On 19 June 2014 19:25, Salz, Rich <[e-mail]> wrote:
> I don't see how #3 "rejects that thesis."  Actually, looking at your note I would disagree with all of your characterization.  To me, #3 says that change is a problem, so explicitly start a new session if you want to change things.
>
>> 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.
>
> I was thinking that since the TCP(whatever) connecdtion was open, both client and server would already "know" who was on the other side, and if the restarted connection ended up with different identities (on either side), it could signal an error to the application.  Or, either side MAY send an alert if the identity is "unexpected" or different. Maybe that's a SHOULD or even a MUST. Also, for I'd expect that the client could now use the 0RT since it has the server's DH key.


That's detail that wasn't clear.  So the idea is that only some
properties would be effectively immutable, and that immutability is
enforced by the stack.  Identity seems like an obvious candidate for
immutability, but that would prevent the spontaneous client
authentication use case.  We'd need careful rules around what can
change, what requires an alert, and what causes the connection to
abort.

I'll note that 0RTT could reduce the amount of dead air, but not
entirely eliminate it.  Server initiated restarts (as opposed to
renegotiation) would lose time if they had to stop sending at that
point.  And for clients, we currently have a limitation with the 0RTT
handshake in that the first flight of data needs to be entirely
contained in the encrypted ClientHello extension.  You can't trickle
data out without risking an explosion from non-1.3 servers.
Obviously, you know that the server talks 1.3, so maybe we can have
different logic here to allow for regular data to flow...  You see
where I'm going?