Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

[Martin Thomson <[e-mail]>]

On 14 October 2015 at 13:29, David Benjamin <[e-mail]> wrote:
> If you really absolutely must support interleave and can't avoid it, I think
> it being allowed everywhere except between CCS and Finished is probably the
> closest you can get to coherent semantics. "Coherent" here is, of course,
> all relative since renego is involved.

I think that it needs to be more than that.  I would say:

1. You should not interleave data with handshake messages from the same flight.
2. You should not report any change to handshake status until the
renegotiation is complete.  That means no callbacks/events about new
peer certificates, or anything of that nature until you have received
and validated the Finished.  You would have to exercise caution here
for the callbacks that are necessary during the process, like the
"please choose a certificate and private key to use" callback on
either side.

If you can somehow manage to do all of that, then you might be able
get away with not halting progress entirely.  Because - as far as the
application is concerned - application data is sent as though it were
before the renegotiation.  In essence, you are keeping the application
ignorant of any changes until the whole process is over.

I've heard it recommended that you add other stipulations, such as

3. The server cannot change certificate.

I'm ambivalent on that because I don't believe it to materially change
the security properties (assuming that we have a good handshake, i.e.,
at least R-I and session hash).  I don't have proof of that, of
course.