Re: [quicwg/base-drafts] Document request forgery (#3996)

[Igor Lubashev <[e-mail]>]

@igorlord commented on this pull request.



> +
+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. 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 NEW_TOKEN frame ({{validate-future}}) offers
+the only option for request forgery during connection establishment.
+
+Clients are not obligated to use the NEW_TOKEN frame. Request forgery attacks
+that rely on the Token field can be avoided if clients do not include a value
+when the server address has changed from when the NEW_TOKEN frame was received.
+
+Clients MUST NOT send a token received in a NEW_TOKEN frame from one server

This MUST NOT is qualified by the subsequent text to a point of being unenforceable, especially due to "shared prefix of a sufficient length".  Since it is up to implementations to choose what "sufficient" is, an implementation could deem "/0", to be "sufficient" and it would be valid.  Since this is unenforceable, it probably warrants a "SHOULD NOT".

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3996#pullrequestreview-467902038