On Tue, Jun 9, 2020 at 12:32 PM Craig Partridge <craig@xxxxxxxxxxxxx> wrote:
Following up on notes from various folks, most notably John K. and Christian H., about checksums and encryption-based integrity protection, I wanted to make a couple of clarifying points.* If you are not worried about an adversary who seeks to alter your data in transit, then integrity protection is a lousy method for ensuring the received data is correct.
I agree with this statement.
However, with that said, we *should* generally be worried about such an adversary and so in general our protocols should have integrity protection at some layer in the stack, and while inefficient, the adversarial requirements also mean that the chance of detecting non-adversarial error is also very high.. As you note in your original email, the issue arises when integrity check failures occur at a layer which cannot recover from them (as has been noted, TLS over TCP but not QUIC). Faced with this, we can do one of three things:
- Create higher layer recovery mechanisms which can recover from lower layer failures (as Richard alluded to with TCP)
- Move to protocols which can recover from errors (e.g., QUIC)
- Improve the non-adversarial checksum (in this case the TCP checksum) so that the chance of undetected non-adversarial error is very low (the topic that kicked off this thread).
It's worth noting that the first two are already happening and will most likely continue regardless of what happens at the lower layers (in part because they need to take the lower layers as they are now).
-Ekr
