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

[ianswett <[e-mail]>]

@ianswett commented on this pull request.

I'm concerned about this new SHOULD NOT, but maybe I'm misunderstanding it?

> +Initial packet protection (Section 5.2 of {{QUIC-TLS}}) makes it difficult for
+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.
+
+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 however are not obligated to use the NEW_TOKEN frame. Request forgery
+attacks that rely on the Token field can be avoided if clients send an empty
+Token field when the server address has changed from when the NEW_TOKEN frame
+was received.
+
+Therefore, clients SHOULD NOT send a token received in a NEW_TOKEN frame from

To clarify, the NEW_TOKEN frame is not received from a server in an Initial packet, correct?  The first few times I read this, I though that was what you intended.

Assuming I'm now reading this correctly, this SHOULD NOT would seem to be very restrictive for domains which use DNS to load balance traffic.  Previously, I assumed that NEW_TOKEN would be used whenever hostnames matched.  Am I understanding correctly?

If we're going to add this normative restriction, I would suggest placing the restriction in the section on address validation/etc and then referencing this section.

-- 
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-483059823