Skip to content
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

Closed
DavidSchinazi opened this issue Feb 27, 2020 · 6 comments · Fixed by #38
Closed

Consider retransmission bit leakage #2

DavidSchinazi opened this issue Feb 27, 2020 · 6 comments · Fixed by #38

Comments

@DavidSchinazi
Copy link
Contributor

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)

@DavidSchinazi
Copy link
Contributor Author

Comment from @mikkelfj on 2020-02-21:

How would that be different from streams in ordinary QUIC? Here you can also drop packets and look for retransmissions of a specific size? If there is overlap, this issue belongs to QUIC transport security considerations in general.

@chris-wood
Copy link

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.

@nibanks
Copy link
Member

nibanks commented May 7, 2020

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.

@martinthomson
Copy link
Member

PING doesn't really cut it here, because presence and size matter.

@tfpauly
Copy link
Contributor

tfpauly commented Jul 12, 2021

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?

@martinthomson
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants