TLS uses TCP, and TCP has checksums and retry logic. It therefore assumes any data corruption that made it all the way to the TLS layer is an unrecoverable scenario, probably indicative of an attack.

The problem here is that the thing computing the TCP checksum on the outgoing frame was the WLAN firmware running on the WLAN NIC itself; this is known as checksum offloading. It saves CPU time if the CPU can just hand off a TCP segment to the NIC and let the NIC checksum it before it sends it out. This only works properly if the data given to the NIC doesn't get corrupted in the meantime.

You do _not_ want to have multiple retry layers if you can help it. That can result in accidentally DoSing yourself, as each layer amplifies the number of retries.

TLS over TCP assumes TCP supplies a reliable uncorrupted stream of data. So it has no retries of its own, and terminates the connection when invalid data arrives.

I assume DTLS and QUIC handle MAC verification failures gracefully, like ordinary packet loss.

TLS expects a reliable connection, if the data are corrupted, that means some is tampering with the connection. It's best to avoid retrying until the tampering succeeds.

[dead]

[flagged]