No protection against packet modification

[martinthomson]

scramble doesn't prevent an attacker from flipping bits as there is no extra authentication tag. In a protocol like QUIC, I think that this is probably OK.

In other similar systems, a damaged packet might cause significant side effects, like session teardown. In QUIC, that packet is simply dropped.

However, if the attacker is aware that the packet would ordinarily cause an observable activity at its destination and it doesn't otherwise have connection ID mappings, then it can use that damage to help correlate packets across a proxy (this is just a variation on the burst thing in the pull request already).

Might be worth pointing out. Because this does not work if you don't have strong integrity protection at the QUIC layer.

[afressancourt]

Hello,

I agree that, in the absence of an authentication tag, there is a possibility that an attacker uses a packet manipulation to track the packet.

One question we need to ask ourselves is whether we want the packet's integrity to be checked at every single hop or end to end. Verifying the integrity end to end does not prevent an attack in which the attacker controls the destination and want to know where the packet is coming from by introducing a bit manipulation at a given proxy or on a given link.

Checking the packet's integrity at every hop would prevent this attack from happening, but then the question is who is responsible for writing the authentication tag checked at a given proxy: is it the source? the proxy before?

[mirjak]

Actually we discussed this attack but as it seems did not add text to the security consideration. I think we should add it.