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

Document request forgery #3996

Merged
merged 13 commits into from Sep 8, 2020
3 changes: 2 additions & 1 deletion draft-ietf-quic-transport.md
Expand Up @@ -6506,7 +6506,8 @@ Clients are able to present a spoofed source address as part of an apparent
connection migration to cause a server to send datagrams to that address.

The Destination Connection ID field in any packets that a server subsequently
sends to this spoofed address can be used for request forgery.
sends to this spoofed address can be used for request forgery. A client might
also be able to influence the ciphertext.

A server that only sends probing packets ({{probing}}) to an address prior to
address validation provides an attacker with only limited control over the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do find it somewhat ironic that address validation might make this worse: the client sending a PATH_CHALLENGE to the server can pretty much guarantee that the server will send a PATH_RESPONSE with client-provided content to the client's spoofed source address. Should we mention that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered it, but thought that the generic text was enough. Note also that there is no guarantee that PATH_RESPONSE is sent on the same path.

Expand Down