miTLS client does not emit alert when encrypted handshakes are shuffled

[oweisse-msft]

The typical order of encrypted messages: encrypted_extensions; certificate; certificate_verify;finished; In this experiment the order was changed, though the record was encrypted properly. i. miTLS client emits no alert, while NSS client emits plaintext alert unexpected_message (which makes sense) ii. In response to NSS client emitting the plaintext alert unexpected_message, miTLS server emits encrypted fatal alert decryption_failed_RESERVED, potentially due to misinterpreting the client alert. iii. After sending decryption_failed_RESERVED, the miTLS server continues to send application data. This is a problem a fatal alert should cause a termination of the communication.

[s-zanella]

This is an interesting test! I assume this is a 1-RTT handshake. I think this explains what's going:

• The miTLS server expects the client to send next an encrypted Finished message. It gets instead a plaintext alert. It sends a decryption_failed_RESERVED alert in response. This is wrong, we should never send such an alert in TLS 1.3 (see https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13-21/draft-ietf-tls-tls13.html#protocol-data-structures-and-constant-values). A fix is to either change TLS.readFragment to send instead a decrypt_error alert. The right fix is to try to parse plaintext alerts and instead send close_notify in response.
• It's ok for a 1.3 server to send application data before receiving the client's Finished message. The miTLS test server does this systematically in a 0-RTT handshake. If this data was buffered before receiving the client's alert it could be sent before sending close_notify and closing the connection. But this is a 1-RTT handshake, so miTLS shouldn't be sending any application data.
• Another case where it's ok for a server to ignore decryption errors is when using trial decryption to check for the end of early data sent by a client in a 0-RTT handshake where the server rejects early data. Again, since this is a 1-RTT handshake, this looks like an error in the logic in StAE.tolerate_decrypt_failure, which appears to tolerate decryption errors even in 1-RTT.

[BarryBo]

Assigning to you. Can you please check if this is still a bug? And if so, it should be caught and fixed during the verification push.