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

From: Martin Thomson <[email-masked]>
Date: Tue, 01 Sep 2020 00:54:07 -0700

@martinthomson commented on this pull request.

> +what packets the peer sends and where these packets are sent. If an attacker
+can target a vulnerable service with a controlled payload, that service might
+perform actions that are attributed to the attacker's peer, but decided by the
+attacker.
+
+For example, cross-site request forgery {{?CSRF=DOI.10.1145/1455770.1455782}}
+exploits on the Web cause a client to issue requests that include authorization
+cookies {{?COOKIE=RFC6265}}, allowing one site access to information and
+actions that are intended to be restricted to a different site.
+
+As QUIC runs over UDP, the primary attack modality of concern is one where an
+attacker can select the address to which its peer sends UDP datagrams and can
+control some of the unprotected content of those packets. As much of the data
+sent by QUIC endpoints is protected, this includes control over ciphertext. An
+attack is successful if an attacker can cause a peer to send a UDP datagram to
+a host that will perform some action based on content in the datagram.

The only place this adds a round trip is for a migration to a preferred address, but that only delays migration, it doesn't prevent the connection from being used.

-- 
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#discussion_r480939918

---

From: Martin Thomson <[email-masked]>
Date: Tue, 01 Sep 2020 15:13:12 -0700

> +frames in packets prior to completing address validation. Note that this does
+not prevent an attacker from using the Destination Connection ID field for an
+attack.
+
+Endpoints are not expected to have specific information about the location of
+servers that could be vulnerable targets of a request forgery attack. However,
+it might be possible over time to identify specific UDP ports that are common
+targets of attacks or particular patterns in datagrams that are used for
+attacks. Endpoints MAY choose to avoid sending datagrams to these ports or not
+send datagrams that match these patterns prior to validating the destination
+address. Endpoints MAY retire connection IDs containing patterns known to be
+problematic without using them.
+
+Note:
+
+: Modifying endpoints to apply these protections is more efficient than

The first requires that the endpoint decide *before* it sends anything.  It can't add a round trip, because that round trip would enable the attack.

-- 
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#discussion_r481461215

---

From: Mike Bishop <[email-masked]>
Date: Wed, 02 Sep 2020 12:33:59 -0700

@MikeBishop commented on this pull request.

The Message Send Service (RFC 1312) seems like a potential target.

>    This service is primarily intended for "open" environments:
>   controlled local area networks used by reasonably trusted
>   participants, in which security considerations may be relaxed in the
>   interests of ease of use and administration. In such an environment
>   it is appropriate to trust the user name and source IP address as
>   identifying the actual sender of the message.

-- 
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#discussion_r482345596

---

From: David Schinazi <[email-masked]>
Date: Wed, 02 Sep 2020 17:48:02 -0700

@DavidSchinazi approved this pull request.

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

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 04 Sep 2020 13:53:51 -0700

@janaiyengar approved this pull request.

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

---

From: ianswett <[email-masked]>
Date: Sat, 05 Sep 2020 12:38:18 -0700

@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

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 08 Sep 2020 15:15:30 -0700

Merged #3996 into master.

-- 
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#event-3743016180