If you rely on the TCP checksum to protect your data you are delusional anyways. The TCP checksum is a simple additive checksum that is very weak and cannot detect wide classes of data corruptions. It is is well known that it won't catch many problems, with classical papers describing this. All it can do is to catch very obvious "big" mistakes.
That is why link layers always have other stronger CRCs too.
This is actually one of the better reasons to always use TLS. Yhe MAC authentication it uses is much stronger.
Yeah, TCP's checksum is indeed weak and TLS is indeed a good answer.
However, I think delusional is a bit of a strong word to use here. "Performance of Checksums and CRCs over Real Data" has a bunch of interesting data about the number oand types of common errors detected by simple checkums and CRC: http://ccr.sigcomm.org/archive/1995/conf/partridge.pdf
You misunderstand the purpose of checksums. Checksums and error correcting codes do no eliminate errors, they reduce the frequency of undetected errors by a known factor.
If a system was designed with the usage of TCP checksums in mind, then removing TCP checksums will create a system with an error rate 4 orders of magnitude higher than before.
I guess that's arguably better than accepting corrupted data, but still a step backwards from the abstraction TCP is intended to provide in regards to checksums ...
TCP checksum and TLS checksum/macing both have use case. Not every protocol built on TCP supports TLS. If TCP checksum is broken, we have to fix it. So I agree with below delusional is too strong. If a simple checksum is buggy, how can I trust anything about said TCP protocol implementation? How can you reassure other data integrity implementation isn't buggy? This bug isn't really about whether TCP checksum is weak or not, rather, just a bug which I suppose most people ignore.
That is why link layers always have other stronger CRCs too.
This is actually one of the better reasons to always use TLS. Yhe MAC authentication it uses is much stronger.