In TLS 1.3 handshake, can an internal error at the client be interpreted as a decrypt error at the server?

Question

In TLS 1.3 handshake protocol, the client sends the ClientHello message to the server. The server then sends back the ServerHello message followed by some encrypted messages. The client then computes keys and sends some other encrypted messages to the server to complete the handshake.

Now, what happens if an error occurs while the client is computing keys? Let's say it's an internal error. The client is supposed to send a fatal "Internal Error" alert to the server and then close the connection. The alert message is certainly not encrypted because the client does not successfully compute keys. However, the server already calculated keys successfully and changed cipher spec, so the server expects all incoming messages to be encrypted. Therefore, a decrypt error will occur when it tries to decrypt the unencrypted alert message from the client. Effectively, an internal error at the client becomes a decrypt error when it reaches the server. Is this an acceptable behavior?

Answer 1

You are assuming that some error can occur which makes it impossible for the client to compute the keys correctly. Assuming that client and server have completed the handshake so far in a correct way, so that the input data for computation of the keys are available at the client and they are correct. Also, assuming that there are no implementation errors. In this case it is very unlikely that some error can happen during computation of the keys at all, i.e. probably only some out of memory condition or some hardware related problems. It might even be that the client is unable to send a message at all to the server in such a situation. I think it is perfectly ok if in this rare case the server cannot distinguish between an "internal error" message from the client and a corrupted message from the client or a connection close with no message at all since the amount of usable information is about the same: something unspecified went wrong.

Apart from that, the alerts sent to the peer do not contain much useful information in the first place. Since there is no real error message but only a single error number it can only point at the direction of the possible cause of an error but not describe it in detail. And when looking at how this alert protocol was used in TLS 1.2 and lower by actual implementations, the chance is high that it will be similar mostly useless in TLS 1.3: there are major implementations which just close the connection on error instead of sending an alert back. Other implementations just send a generic handshake_failure in most cases even though there are more exact alert types available for the particular error.