-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider retransmission bit leakage #2
Comments
I think the key here is that, in dropping the special datagram frame and not seeing anything retransmitted, one could learn something about what was sent. |
If we take my recommendation in #8 to always at least send out a PING frame/packet for PTOs or losses of DATAGRAM frame/packets then, it may mitigate this leakage some. There would always be something sent out on these selective losses. I'm not sure how hard it would be to determine if the lost packet was a DATAGRAM or not with this behavior. My guess is that it would be implementation dependent. |
PING doesn't really cut it here, because presence and size matter. |
Does the attacker have a way of knowing that the packet that was dropped contained a DATAGRAM, vs some other non-retransmitted frame, such as PADDING or PING or ACK? |
Probably not, though I would say that the retransmission logic for those three frames could be different enough that the choice of frame might leak. Nothing much doing here, though we might note that retransmission logic might expose information that can be used for traffic analysis. |
Rephrasing what I mentioned at the mic, imagine a scenario where an application uses DATAGRAM to send a single fixed message ("fire the missile"). An adversary on path can start selectively dropping packets and checking to see whether or not they're retransmitted to learn whether or not this special message was sent. (Retransmission detection could be done by looking at the size of the QUIC packet carrying the DATAGRAM, for example.)
I don't claim this is easy to do in practice, or useful, but I think it does raise interesting questions about how this new frame affects QUIC's security posture. Perhaps some text in the security considerations is needed?
(Issue copied from individual draft repo, by @chris-wood on 2019-11-19)
The text was updated successfully, but these errors were encountered: