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.

Sign up for GitHub

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

Jump to bottom

Document request forgery #3996

Merged
merged 13 commits into from Sep 8, 2020
Merged

Document request forgery #3996

Changes from 1 commit
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
a66b21e
Document request forgery
martinthomson Aug 13, 2020
951da28
Use a reference with a DOI that I can find
martinthomson Aug 13, 2020
e80ca89
Many small corrections
martinthomson Aug 14, 2020
d273e12
Control is via DNS
martinthomson Aug 14, 2020
aaf51ff
We assume this limitation, though it might not be necessarily true
martinthomson Aug 14, 2020
3e64135
Take suggestions from Lucas and massage a bit
martinthomson Aug 14, 2020
718b774
Wrap suggestion
martinthomson Aug 14, 2020
5e7f92e
SHOULD NOT reuse tokens; to allow for all those exceptions
martinthomson Aug 17, 2020
dfc8827
Much JanaIyengar review feedback
martinthomson Aug 19, 2020
4252d1c
Some residual cleanup
martinthomson Aug 20, 2020
1cfbb7f
Make the preferred address change prominent
martinthomson Aug 31, 2020
a587bf0
Mention ciphertext malleability
martinthomson Aug 31, 2020
7adbc31
This is not a true defense
martinthomson Sep 1, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
10 changes: 5 additions & 5 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -6390,8 +6390,8 @@ attacks and describes countermeasures that can be implemented by QUIC
endpoints. These actions are described on the assumption that potential targets
for request forgery attacks take no action to protect against these attacks.
While target services are encouraged to implement better protections, such as
strong authentication that does not rely on implicit signals, the goal of this
section is to describe mitigations that can be employed unilaterally by a QUIC
strong authentication that does not rely on implicit signals, this section
describes mitigations that can be employed unilaterally by a QUIC
implementation or deployment.


Expand Down Expand Up @@ -6448,9 +6448,9 @@ other types of packet to a destination that does not understand QUIC or is not
willing to accept a QUIC connection.

Initial packet protection (Section 5.2 of {{QUIC-TLS}}) makes it difficult for
servers to control the content of Initial packets. A client choosing an
unpredictable Destination Connection ID ensures that servers are unable to
control any of the encrypted portion of Initial packets from clients.
servers to control the content of Initial packets sent by clients. A client
choosing an unpredictable Destination Connection ID ensures that servers are
unable to control any of the encrypted portion of Initial packets from clients.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't believe that this is correct as written if there is a Retry because the server gets to control the next DCID. I don't think that this is relevant because you would need a round trip to make it work (I think!) but...

Copy link
Contributor

Choose a reason for hiding this comment

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

This is mentioned in the last paragraph of this section. Perhaps we just need to reference that here?


However, the Token field is open to server control and does allow a server to
use clients to mount request forgery attacks. Use of tokens provided with the
Expand Down