# Are applications aware of data records received before and after tls rehandshake?

It seems that a tls endpoint can pump more data records even when it has received a re-handshake request from peer.

Also in dtls, new data records would get accepted even while rehandshake is in progress since any of the endpoint does not have way to tell whether those records originated after a handshake message. This is because re-transmission of handshake message gets a new record protocol header sequence number. So looking at record protocol header sequence number is not a good way to tell the ordering of events.

Do the endpoints have any way to tell which data they received before re-handshake completed and which one they received after rehandshake?

Section II-B talks about this. The answer to this is implementation-dependent. For example, if you're using GnuTLS, you can get some non-fatal error codes if you try to read after parameters change. Then you can look in your logs and distinguish data from before you got the error code from data that's timestamped afterwards. But you may have to be actively looking or polling for it.