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

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Aug 2020 00:31:52 -0700

First cut at this, sorry about it being so long.  It&#39;s fairly hard to
write this, particularly since the existing documentation is so sparse.
Hopefully this is clear enough.  I haven&#39;t had time to properly
proof-read it, so it&#39;s probably not very good.  But I thought I&#39;d share
what I got.

This includes some basic countermeasures, but they aren&#39;t very good.
I think that&#39;s OK, but we should discuss.

Closes #3995.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3996

-- Commit Summary --

  * Document request forgery

-- File Changes --

    M draft-ietf-quic-transport.md (214)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3996.patch
https://github.com/quicwg/base-drafts/pull/3996.diff

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Aug 2020 00:43:31 -0700

@martinthomson pushed 1 commit.

951da28eba29af1df230035fc0dc512baf812af3  Use a reference with a DOI that I can find

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3996/files/a66b21eda0289e756188f3de712b21b49b199679..951da28eba29af1df230035fc0dc512baf812af3

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Aug 2020 05:20:29 -0700

@kazuho commented on this pull request.

I think there are some errors (left comments), but this looks good.

> +address validation; see {{address-validation}}.
+
+Outside of the encrypted portion of packets, QUIC offers an endpoint several
+options for controlling the content of UDP datagrams that a peer sends. The
+Destination Connection ID field offers direct control over early bytes of every
+packet sent by a peer; see {{connection-id}}. The Token field in Initial
+packets offers a server control over other bytes of Initial packets; see
+{{packet-initial}}.
+
+There are no measures in the protocol to prevent indirect control over the
+encrypted portions of packets. it is necessary to assume that endpoints are
+able to control the contents of frames that a peer sends, especially those
+frames that convey application data, such as STREAM frames. Though this depends
+to some degree on details of the application protocol, some control is possible
+in many protocol usage contexts. As the attacker has access to packet
+protection keys, they are able to predict how a peer will encrypt future

```suggestion
protection keys, they are likely to be capable of predicting how a peer will encrypt future
```

While it is true that all the cipher-suites defined in the TLS drafts share this property, I do not think that is a prerequisite of AEAD ciphers in general?

> +migration to a non-loopback address if the same service was previously
+available over a different interface or the address was provided by a service
+at a non-loopback address. Endpoints that depend on these capabilities could
+offer an option to disable these protections.
+
+Similarly, endpoints could regard a change in address to link-local address
+{{?RFC4291}} or an address in a private use range {{?RFC1918}} from a global,
+unique-local {{?RFC4193}}, or non-private address as a potential attempt at
+request forgery. Endpoints could refuse to use these addresses entirely, but
+that carries a significant risk of interfering with legitimate cases. Endpoints
+SHOULD NOT refuse to use an address unless they have specific knowledge about
+the network that indicates that sending datagrams to unvalidated addresses in a
+given range is not safe.
+
+Endpoints MAY choose to reduce the risk of request forgery by not including
+values from NEW_TOKEN frames in Initial packets or by only sending non-probing

```suggestion
values from NEW_TOKEN frames in Initial packets or by only sending probing
```

> +frames in packets prior to completing address validation. Note that this might
+not constrain some attacks as it does not prevent an attacker from using the
+Destination Connection ID field.
+
+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 that
+match these patterns prior to validating the target 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 that

```suggestion
: Modifying endpoints to apply these protections is more efficient than
```

> +against attacks that use spoofing and originate from an external network.
+
+
+### Generic Request Forgery Countermeasures {#forgery-generic}
+
+The most effective defense against request forgery attacks is to modify
+vulnerable services to use strong authentication. However, this is not always
+possible when deploying QUIC. This section outlines some others steps that QUIC
+endpoints could take. These additional steps are all discretionary as,
+depending on circumstances, they could interfere with or prevent legitimate
+uses.
+
+Services offered over loopback interfaces (that is, ::1 or 127.0.0.1) often
+lack proper authentication. Endpoints MAY prevent connection attempts or
+migration to a loopback address. Endpoints SHOULD NOT allow connections or
+migration to a non-loopback address if the same service was previously

```suggestion
migration to a loopback address if the same service was previously
```

I'm not sure, but maybe this is the intent?

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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 13 Aug 2020 07:56:39 -0700

@huitema commented on this pull request.

That's nice, but in many scenarios any of the node addresses can be used to reach services local to the node, in the same way as loopback addresses. In server farm scenarios, this requires guessing the local IP of the specific server, but that can probably be done. Same for clients behind NAT.

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

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 13 Aug 2020 07:57:41 -0700

@LPardue commented on this pull request.

> +  to use source address spoofing to select where a server sends subsequent
+  datagrams.
+
+These three options all involve cases where an endpoint sends datagrams to a
+host that might not understand QUIC. That is, these packets are sent prior to

```suggestion
encrypted portions of packets. It is necessary to assume that endpoints are
```

> +Unlike other packets, packet protection provides good protection against
+control over the contents of Initial packets. The choice of an unpredictable
+Destination Connection ID by clients ensures that servers are unable to control
+any of the encryption portion of Initial packets.

This para's grammar hurts my head. Alternative might be

"Initial packet protection provides resilience to control of contents by servers. Client choice of an unpredictable Destination Connection ID ensures servers are unable to control any of the encrypted portion of Initial packets."

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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 13 Aug 2020 07:59:55 -0700

There is indeed a valid scenario for client and server discovering that they are behind the same NAT. Wasn't that scenario addressed in Web-RTC using a discovery protocol involving temporary names, in an attempt at privacy? 

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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 13 Aug 2020 08:03:20 -0700

I like the general text. I am worried that the response to these attacks may need to evolve over time as we understand them better. I was looking at ways to say that. No specific suggestion yet.

-- 
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#issuecomment-673531456

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 13 Aug 2020 15:10:08 +0000 (UTC)

Then I might concate the next paragraph to this and say

"However, the Token field is open to control and does allow a server to use clients to mount request forgery attacks."

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

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Aug 2020 12:14:56 -0700

@MikeBishop commented on this pull request.

> +endpoints. These actions are described on the assumption that potential targets
+for request forgery attacks take no action to protect against these attacks.
+While it would be ideal if target services implement better protections, such
+as strong authentication that does not rely on implicit signals, the goal of
+this section is to describe what a QUIC implementation or deployment can do.
+
+
+### Control Options for Endpoints
+
+QUIC offers some opportunities for endpoints to influence or control where
+their peers send UDP datagrams.
+
+Control over the destination of UDP datagrams presents three options for
+request forgery attack:
+
+* initial connection establishment ({{handshake}}), where a server is able to

```suggestion
* initial connection establishment ({{handshake}}), where a DNS resolver is able to
```
The server itself has no such control; it's the DNS server that can be used to misdirect these packets.

+packets offers a server control over other bytes of Initial packets; see
+{{packet-initial}}.
+
+There are no measures in the protocol to prevent indirect control over the
+encrypted portions of packets. it is necessary to assume that endpoints are
+able to control the contents of frames that a peer sends, especially those
+frames that convey application data, such as STREAM frames. Though this depends
+to some degree on details of the application protocol, some control is possible
+in many protocol usage contexts. As the attacker has access to packet
+protection keys, they are able to predict how a peer will encrypt future
+packets. Successful control over datagram content then only requires that the
+attacker be able to predict the packet number and placement of frames in
+packets with some amount of reliability.
+
+Limiting control over datagram content is considered infeasible. The primary

Eliminating it completely is infeasible.  Limiting it certainly seems possible.  As a simple precaution, an implementation might opt to break up large STREAM/CRYPTO frames and then randomize the order of frames while building the packet, distributing any padding to be added between frames instead of appending it.

There's no requirement or even substantial performance impact if the stream bytes are out-of-order within the packet.

> +sent prior to address validation.
+
+
+### Request Forgery with Initial Packets
+
+Servers are assumed to be able to choose the IP address and port on which they
+advertise their availability, so Initial packets from clients are assumed to be
+available for use in this sort of attack. The address validation implicit in
+the handshake ensures that - for a new connection - a client will not send
+other types of packet to a destination that does not understand QUIC and is
+willing to accept connections.
+
+Unlike other packets, packet protection provides good protection against
+control over the contents of Initial packets. The choice of an unpredictable
+Destination Connection ID by clients ensures that servers are unable to control
+any of the encryption portion of Initial packets.

```suggestion
any of the encrypted portion of Initial packets.
```

+### Request Forgery with Initial Packets
+
+Servers are assumed to be able to choose the IP address and port on which they
+advertise their availability, so Initial packets from clients are assumed to be
+available for use in this sort of attack. The address validation implicit in
+the handshake ensures that - for a new connection - a client will not send
+other types of packet to a destination that does not understand QUIC and is
+willing to accept connections.
+
+Unlike other packets, packet protection provides good protection against
+control over the contents of Initial packets. The choice of an unpredictable
+Destination Connection ID by clients ensures that servers are unable to control
+any of the encryption portion of Initial packets.
+
+The only field in an Initial packets that is open to server control is the

```suggestion
The only field in Initial packets that is open to server control is the
```

> +length as being functionally equivalent (for instance, /24 in IPv4 or /56 in
+IPv6). In addition, clients SHOULD treat a preferred address that is
+successfully validated as equivalent to the address on which the connection was
+made; see {{preferred-address}}.
+
+Sending a Retry packet ({{packet-retry}}) offers a server the option to change
+the Token field. After sending a Retry, the server can also control the
+Destination Connection ID field of subsequent Initial packets from the client.
+This also might allow indirect control over the encrypted content of Initial
+packets. However, the exchange of a Retry packet validates the server address,
+thereby preventing the use of subsequent Initial packets for request forgery.
+
+
+### Request Forgery with Preferred Addresses
+
+Servers can specify a preferred address, which clients then to migrate to after

```suggestion
Servers can specify a preferred address, which clients then migrate to after
```

+

I think that's true.  An encryption algorithm that incorporated, say, an input salt would have unpredictable output even given predictable plaintext.

Of course, that's probably equivalent to appending some random bytes to the input plaintext, then dropping those bytes following decryption.  If we wanted to, would that be a potential mitigation?

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Aug 2020 21:31:40 -0700

e80ca89a63ff8d0313534b58e1d0dfc2c667b8be  Many small corrections

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3996/files/951da28eba29af1df230035fc0dc512baf812af3..e80ca89a63ff8d0313534b58e1d0dfc2c667b8be

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Aug 2020 21:31:53 -0700

@martinthomson pushed 3 commits.

d273e12b888ebd5dcd0c659c9e14b8202dccc3ca  Control is via DNS
aaf51ffa3a6db55aa3c125d71f13ed2abda4f5f2  We assume this limitation, though it might not be necessarily true
3e64135ab73339bfb719398c1954db43a95e00b4  Take suggestions from Lucas and massage a bit

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3996/files/e80ca89a63ff8d0313534b58e1d0dfc2c667b8be..3e64135ab73339bfb719398c1954db43a95e00b4

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Aug 2020 21:34:56 -0700

718b774c016cdaae871d48252fb5dc92afa6968a  Wrap suggestion

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3996/files/3e64135ab73339bfb719398c1954db43a95e00b4..718b774c016cdaae871d48252fb5dc92afa6968a

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 14 Aug 2020 15:16:19 -0700

@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

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 14 Aug 2020 15:32:09 -0700

@huitema This is certainly a way to mount an attack on services that assume that they are serving friendly clients and the network perimeter is secure.  It happens, especially when services listen only on RFC1918/unique-local or link-local IPs.  It happens even more often with services only listen to loopback and, therefore, think they are immune to any threats coming from outside of the host.

That's why I'd generalize this from "non-loopback -> loopback" to “globally routable IP space” -> “RFC1918/unique-local IP space” -> “link-local” -> “loopback”.

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 18 Aug 2020 15:49:40 -0700

@MikeBishop 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-469881716

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 19 Aug 2020 00:47:29 -0700

@janaiyengar commented on this pull request.

Thank you for writing this up! A few comments; almost all are editorial suggestions. Only a couple of questions.

> @@ -6357,6 +6357,217 @@ this behavior.  An endpoint can then immediately close the connection with a
 connection error of type PROTOCOL_VIOLATION; see {{immediate-close}}.

+## Request Forgery Attacks
+
+A request forgery attack occurs where one endpoint causes its peer to perform

```suggestion
A request forgery attack occurs where an endpoint causes its peer to perform
```

> @@ -6357,6 +6357,217 @@ this behavior.  An endpoint can then immediately close the connection with a
 connection error of type PROTOCOL_VIOLATION; see {{immediate-close}}.

+## Request Forgery Attacks
+
+A request forgery attack occurs where one endpoint causes its peer to perform
+some unwanted action, such as issuing a request. Request forgery attacks aim to

I'm not clear on the terminology here, but isn't "request forgery" by definition limited to the action of issuing a request? If so, maybe this could be "causes its peer to issue a request towards a victim, where the request is crafted by the endpoint to inflict damage on the victim.".

> +forgery attack is often used to gain access to implicit authorization conferred
+by their peer's location in the network.

```suggestion
forgery attack is often used to exploit any implicit authorization conferred
on the peer by the victim due to the peer's location in the network.
```

> @@ -6357,6 +6357,217 @@ this behavior.  An endpoint can then immediately close the connection with a
 connection error of type PROTOCOL_VIOLATION; see {{immediate-close}}.

+## Request Forgery Attacks
+
+A request forgery attack occurs where one endpoint causes its peer to perform
+some unwanted action, such as issuing a request. Request forgery attacks aim to
+provide an attacker with access to certain capabilities of its peer that might
+otherwise be unavailable to the attacker. For a networking protocol, a request
+forgery attack is often used to gain access to implicit authorization conferred
+by their peer's location in the network.
+
+For request forgery to be effective, an attacker needs to be able to influence
+what their peer sends, and where it is sent. If an attacker can target a

```suggestion
what packets the peer sends, and to which target. If an attacker can target a
```

> +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.

```suggestion
```

This seems unnecessary. Not a strong suggestion, but this could be removed with little loss of useful information.

> +otherwise be unavailable to the attacker. For a networking protocol, a request
+forgery attack is often used to gain access to implicit authorization conferred
+by their peer's location in the network.
+
+For request forgery to be effective, an attacker needs to be able to influence
+what their peer sends, and where it is 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

```suggestion
Since this version of QUIC runs over UDP, the primary attack modality of concern is one where an
```

> +forgery attack is often used to gain access to implicit authorization conferred
+by their peer's location in the network.
+
+For request forgery to be effective, an attacker needs to be able to influence
+what their peer sends, and where it is 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 IP address and port to which a peer sends UDP datagrams

```suggestion
attacker can select the address to which its peer sends UDP datagrams
```

> +by their peer's location in the network.
+
+For request forgery to be effective, an attacker needs to be able to influence
+what their peer sends, and where it is 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 IP address and port to which a peer sends UDP datagrams
+and also controls some of the unprotected content of those packets. As much of

```suggestion
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

I don't understand this -- how does  the attack include control over ciphertext? I had assumed the interesting attacks here were through the unencrypted parts of the packet.

> +UDP datagram to a host that will perform some action based on content in the
+datagram that the attacker is able to control or influence.

```suggestion
UDP datagram to a host causing it to perform some action based on content in the
datagram that the attacker is able to control or influence.
```

```suggestion
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 describes mitigations that can be employed unilaterally by a QUIC
implementation or deployment.
```

```suggestion
QUIC offers some opportunities for an attacker to influence or control where
its peer sends UDP datagrams.
```

+request forgery attack:

```suggestion
```
Remove this and move the colon to the end of the previous sentence.

```suggestion
In all three cases, the attacker can cause its peer to send datagrams to a
victim that might not understand QUIC. That is, these packets are sent by
the peer prior to address validation; see {{address-validation}}.
```

> +* initial connection establishment ({{handshake}}), where a server is able to
+  choose where a client sends datagrams, for example by populating DNS records;
+
+* preferred addresses ({{preferred-address}}), where a server is able to choose
+  where a client sends datagrams; and
+
+* spoofed connection migrations ({{address-spoofing}}), where a client is able
+  to use source address spoofing to select where a server sends subsequent
+  datagrams.
+
+These three options all involve cases where an endpoint sends datagrams to a
+host that might not understand QUIC. That is, these packets are sent prior to
+address validation; see {{address-validation}}.
+
+Outside of the encrypted portion of packets, QUIC offers an endpoint several
+options for controlling the content of UDP datagrams that a peer sends. The

```suggestion
options for controlling the content of UDP datagrams that its peer sends. The
```

```suggestion
Destination Connection ID field offers direct control over bytes that appear early
in packets sent by the peer; see {{connection-id}}. The Token field in Initial
```

> +* spoofed connection migrations ({{address-spoofing}}), where a client is able

```suggestion
There are no measures in this version of QUIC to prevent indirect control over the
```

> +encrypted portions of packets. It is necessary to assume that endpoints are

This sentence is unclear --  to what end is it necessary to assume this? (I'm having some trouble understadning the rest of this para too, I'll try it again tomorrow.)

> +This section assumes that limiting control over datagram content is not
+feasible. The focus of the mitigations in subsequent sections is on limiting

I am assuming you mean to say that limiting this for the purposes of mitigating is not feasible. Perhaps phrase it as "It is reasonable to assume that mitigations that require limitations on datagram content are not feasible. Therefore, the focus of the mitigations ..."

> +the ways to use datagrams that are sent prior to address validation for request
+forgery.

```suggestion
the ways in which datagrams that are sent prior to address validation can be used
for request forgery.
```

+frames that convey application data, such as STREAM frames. Though this depends
+to some degree on details of the application protocol, some control is possible
+in many protocol usage contexts. As the attacker has access to packet protection
+keys, they are likely to be capable of predicting how a peer will encrypt future
+packets. Successful control over datagram content then only requires that the
+attacker be able to predict the packet number and placement of frames in packets
+with some amount of reliability.
+
+This section assumes that limiting control over datagram content is not
+feasible. The focus of the mitigations in subsequent sections is on limiting
+the ways to use datagrams that are sent prior to address validation for request
+forgery.
+
+
+### Request Forgery with Initial Packets

```suggestion
### Request Forgery with Client Initial Packets
```

```suggestion
An attacker acting as a server can choose the IP address and port on which it
advertises its availability, so Initial packets from clients are assumed to be
```

```suggestion
other types of packet to a destination that does not understand QUIC.
```

An endpoint that does not understand QUIC cannot be willing to accept QUIC connections.

> +feasible. The focus of the mitigations in subsequent sections is on limiting
+the ways to use datagrams that are sent prior to address validation for request
+forgery.
+
+

```suggestion
servers to control the content of Initial packets from clients. A client choosing an
```

Split the para at "However" and combine with the following para.

"Clients however are not ..."

```suggestion
that rely on the Token field can be avoided if clients do not include a value
```

```suggestion
Therefore, clients MUST NOT send a token received in a NEW_TOKEN frame from one server
```

+Clients MUST NOT send a token received in a NEW_TOKEN frame from one server
+address in an Initial packet that is sent to a different server address. As
+strict equality might reduce the utility of this mechanism, clients MAY employ
+heuristics that result in different server addresses being treated as
+equivalent, such as treating addresses with a shared prefix of sufficient
+length as being functionally equivalent (for instance, /24 in IPv4 or /56 in
+IPv6). In addition, clients SHOULD treat a preferred address that is
+successfully validated as equivalent to the address on which the connection was
+made; see {{preferred-address}}.
+
+Sending a Retry packet ({{packet-retry}}) offers a server the option to change
+the Token field. After sending a Retry, the server can also control the
+Destination Connection ID field of subsequent Initial packets from the client.
+This also might allow indirect control over the encrypted content of Initial
+packets. However, the exchange of a Retry packet validates the server address,

```suggestion
packets. However, the exchange of a Retry packet validates the server's address,
```

> +The Destination Connection ID field of packets that the client sends to a
+preferred address can be used for request forgery.

merge with previous para

+Destination Connection ID field of subsequent Initial packets from the client.
+This also might allow indirect control over the encrypted content of Initial
+packets. However, the exchange of a Retry packet validates the server address,
+thereby preventing the use of subsequent Initial packets for request forgery.
+
+
+### Request Forgery with Preferred Addresses
+
+Servers can specify a preferred address, which clients then migrate to after
+confirming the handshake; see {{preferred-address}}.
+
+The Destination Connection ID field of packets that the client sends to a
+preferred address can be used for request forgery.
+
+A client SHOULD NOT send non-probing frames to a preferred address prior to

Why not a MUST NOT? What reasons do we have to allow this to happen?

> +This document does not offer any additional specific countermeasures that can
+be implemented by endpoints aside from the generic measures described in
+{{forgery-generic}}.

Why is this paragraph useful? It doesn't seem to follow from the previous text, so it seems to be out of place. Did you mean to connect it in some way?

Also, the requirements above _are_ countermeasures, aren't they?

"However, this is not always possible when deploying QUIC." This seems to suggest that it's a weakness of QUIC. I suspect what you are trying to say is that perhaps "However, this may not always be within the control of the QUIC deployment. This section outlines steps that QUIC endpoints could take to unilaterally protect against such attacks."

> +by endpoints aside from the generic measures described in {{forgery-generic}}.
+However, countermeasures for address spoofing at the network level, in
+particular ingress filtering {{?BCP38=RFC2267}}, are especially effective

```suggestion
Services offered over loopback interfaces (that is, the IPv6 address ::1 or the IPv4 address 127.0.0.1) often
```

+uses.
+
+migration to a loopback address if the same service was previously

```suggestion
that carries a significant risk of interfering with legitimate uses. Endpoints
```

+migration to a loopback address if the same service was previously

```suggestion
the network indicating that sending datagrams to unvalidated addresses in a
```

+
+migration to a loopback address if the same service was previously

```suggestion
available at a different address, or if the address was was provided by a service
```

```suggestion
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.
```

```suggestion
attacks. Endpoints MAY 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.
```

+: Modifying endpoints to apply these protections is more efficient than
+  deploying network-based protections, as endpoints don't need to perform

```suggestion
  deploying network-based protections, as endpoints do not need to perform
```

Since there's a large escape hatch below, I agree that perhaps a SHOULD NOT is better here. The following text effectively explains why this isn't a MUST 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-470158582

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Aug 2020 02:54:32 -0700

@martinthomson pushed 2 commits.

5e7f92e3848a907d9503a218042b4a7ac9a051d6  SHOULD NOT reuse tokens; to allow for all those exceptions
dfc8827197fd9f3590acb897a7052f253eb4ccc9  Much JanaIyengar review feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3996/files/718b774c016cdaae871d48252fb5dc92afa6968a..dfc8827197fd9f3590acb897a7052f253eb4ccc9

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Aug 2020 02:54:47 -0700

@martinthomson commented on this pull request.

Thanks Jana,

I started applying these, then realized that I needed to rewrap and make other tweaks, so I've just made most of these changes, verbatim, as part of a manual commit.

I'm at SHOULD NOT on my copy already.  I guess I forgot to push it.

I wanted to connect this with something that has a lot of existing documentation and explanatory material.  I found relatively little good material on the subject.

I think I will pass on this one.  QUIC (this version, or invariants) run over UDP.

We use a stream cipher, which is essentially an XOR with a predictable sequence.  If you know what the sequence is (this is trivial if you have the keys, just encrypt all zero values), then you know what the transform is and then, you can choose plaintext that is the XOR of the ciphertext you want.

This goes back to the encryption-by-XOR from above.  If I can control plaintext and make some good guesses about where it might appear, then I can control ciphertext.

It would also be reasonable to implement some countermeasures that prevented control over datagram content.  The ciphertext fix does costs a lot though (it's a major change to the protocol that likely has a significant performance impact or requires the use of new ciphers) and it is not sufficient either as there are other more serious problems, like the SPA+connection ID one that I think we've agreed is too valuable a feature to dispense with (and options without this exposure are likely intractable for some server deployments).

I could write all of that down, but I thought it better to just state the assumption.

I think that was supposed to be "....or is not willing to accept a QUIC connection"

I'm good with MUST NOT.

These countermeasures are not comprehensive.  Hence "additional".  Re-reading this though, I felt the need to reword...

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 19 Aug 2020 06:54:12 -0700

@janaiyengar, I agree with you that full control seems a little far-fetched, but depending on the protocol and the scenario, partial control seems really plausible.  At the most basic, consider an echo service over QUIC; you have complete control over the contents of the STREAM frames the peer sends, and if you know the peer's implementation, the packet formation is likely predictable as well unless they deliberately randomize it.  Couple that with victims who will skip junk bytes....

I think Martin's correct that, while no attacker will actually have 100% control over the ciphertext, which parts they do control will be difficult to guarantee.  So we have to evaluate the attack as if they have control over all of it.

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 19 Aug 2020 06:55:04 -0700

If you take Jana's suggestion, ~~the goal of~~

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

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 19 Aug 2020 11:31:20 -0700

I think it's useful to clarify that this is not about the Initial packets from the server, which are trivially controllable.

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

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 19 Aug 2020 11:53:02 -0700

@janaiyengar approved this pull request.

This is good. Thank you for working through the comments, @martinthomson !

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Aug 2020 17:20:44 -0700

4252d1c829ea10800bc86fedb359e328782170f3  Some residual cleanup

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3996/files/dfc8827197fd9f3590acb897a7052f253eb4ccc9..4252d1c829ea10800bc86fedb359e328782170f3

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 19 Aug 2020 20:43:06 -0700

This has been around for a week now and I've heard no serious concerns but a fair bit of support. I'm marking this proposal-ready.

-- 
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#issuecomment-676961718

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 20 Aug 2020 20:45:09 -0700

@martinthomson Thank you for all the efforts that have gone into this PR.

Rereading it, I wonder if we should be talking about 0-RTT too, I think that 0-RTT can be also used as an attack vector. The attacker has the knowledge regarding the packet protection keys that will be used for 0-RTT, and it is easy to guess what packet number will be used.

Based on that, much like NEW_TOKEN tokens, I think it might be the case that we have to recommend to _not_ use 0-RTT when the client resumes a connection to a different server address.

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Aug 2020 19:10:40 -0700

A server might be able to control 0-RTT content, but it can't control 0-RTT keys because those are derived from the ClientHello, which includes a nonce value the server can't predict (ClientHello.random).  I note here that this is true for our TLS integration, but might not be true for other cryptographic handshakes.

-- 
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#issuecomment-678867306

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 23 Aug 2020 19:17:31 -0700

@martinthomson Thanks. Of course you are correct. I was only think about Early Secret, a value that can be estimated by the server. But in this case, it is client_early_traffic_secret that matters, and that incorporates ClientHello.

-- 
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#issuecomment-678868809

---

From: ekr <[email-masked]>
Date: Fri, 28 Aug 2020 10:17:06 -0700

@ekr commented on this pull request.

> +used for request forgery.
+
+
+### Request Forgery with Client Initial Packets
+
+An attacker acting as a server can choose the IP address and port on which it
+advertises its availability, so Initial packets from clients are assumed to be
+available for use in this sort of attack. The address validation implicit in
+the handshake ensures that - for a new connection - a client will not send
+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 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.

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

> +A client MUST NOT send non-probing frames to a preferred address prior to
+validating that address; see {{address-validation}}. This greatly reduces the
+options that a server has to control the encrypted portion of datagrams.
+
+This document does not offer any additional countermeasures that are specific
+to use of preferred addresses and can be implemented by endpoints. The generic
+measures described in {{forgery-generic}} could be used as further mitigation.
+
+
+### Request Forgery with Spoofed Migration
+
+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.

Actually, I think not just DCID. Consider a (contrived) protocol in which the server was able to dictate the contents of the client's plaintext message. Because the server knows the keys, it can then produce any ciphertext of its choice.

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

---

From: ekr <[email-masked]>
Date: Fri, 28 Aug 2020 10:18:47 -0700

While the above is contrived, the server *does* have control of some things. For instance, I can control some of the content of GETs or ACKs.

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

---

From: David Schinazi <[email-masked]>
Date: Fri, 28 Aug 2020 13:53:39 -0700

@DavidSchinazi requested changes on this pull request.

Overall I do think that this PR is going in the right direction, but I don't think it's quite ready to be merged yet.

+Therefore, clients SHOULD NOT send a token received in a NEW_TOKEN frame from
+one server address in an Initial packet that is sent to a different server
+address. As strict equality might reduce the utility of this mechanism, clients
+MAY employ heuristics that result in different server addresses being treated
+as equivalent, such as treating addresses with a shared prefix of sufficient
+length as being functionally equivalent (for instance, /24 in IPv4 or /56 in
+IPv6). In addition, clients SHOULD treat a preferred address that is
+successfully validated as equivalent to the address on which the connection was
+made; see {{preferred-address}}.
+
+Sending a Retry packet ({{packet-retry}}) offers a server the option to change
+the Token field. After sending a Retry, the server can also control the
+Destination Connection ID field of subsequent Initial packets from the client.
+This also might allow indirect control over the encrypted content of Initial
+packets. However, the exchange of a Retry packet validates the server's

Do we have text that explicitly mandates that replies to a RETRY packet MUST be sent to the same address?

+Destination Connection ID field of subsequent Initial packets from the client.
+This also might allow indirect control over the encrypted content of Initial
+packets. However, the exchange of a Retry packet validates the server's
+address, thereby preventing the use of subsequent Initial packets for request
+forgery.
+
+
+### Request Forgery with Preferred Addresses
+
+Servers can specify a preferred address, which clients then migrate to after
+confirming the handshake; see {{preferred-address}}. The Destination Connection
+ID field of packets that the client sends to a preferred address can be used
+for request forgery.
+
+A client MUST NOT send non-probing frames to a preferred address prior to

Seeing this normative requirement in Security Considerations makes me uneasy as an implementer might miss it. Could we instead move the `MUST NOT` to the section that defines preferred_address and then only reference it here?

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

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?

> +Services offered over loopback interfaces (that is, the IPv6 address ::1 or the
+IPv4 address 127.0.0.1) often lack proper authentication. Endpoints MAY prevent
+connection attempts or migration to a loopback address. Endpoints SHOULD NOT
+allow connections or migration to a loopback address if the same service was
+previously available at a different interface or if the address was provided by
+a service at a non-loopback address. Endpoints that depend on these
+capabilities could offer an option to disable these protections.
+
+Similarly, endpoints could regard a change in address to link-local address
+{{?RFC4291}} or an address in a private use range {{?RFC1918}} from a global,
+unique-local {{?RFC4193}}, or non-private address as a potential attempt at
+request forgery. Endpoints could refuse to use these addresses entirely, but
+that carries a significant risk of interfering with legitimate uses. Endpoints
+SHOULD NOT refuse to use an address unless they have specific knowledge about
+the network indicating that sending datagrams to unvalidated addresses in a
+given range is not safe.

The recommendation in this paragraph is confusing to me. It somewhat concludes that this is a problem but contradicts itself in saying that implementers should both not allow migration and not refuse migration. I would prefer we figure out which strategy is best and recommend it instead of this.

> +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.

Could we add a paragraph here that provides examples of real harm? What protocols are both UDP-based and non-authenticated in a way that would make them vulnerable to a request forgery from a QUIC stack?

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

This depends on what you mean by efficient. Some of the recommendations in this section will add a round-trip which is not efficient.

I think you're referring to [draft-ietf-rtcweb-mdns-ice-candidates](https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates). For us to do something like that we'd need a way to convey hostnames in preferred_address or elsewhere, and I'm not sure we should be doing that.

+
+

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

Isn't that prevented by address validation?

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Aug 2020 17:52:00 -0700

1cfbb7fdec57f73d8921736e093f7dd2e29b7974  Make the preferred address change prominent

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3996/files/4252d1c829ea10800bc86fedb359e328782170f3..1cfbb7fdec57f73d8921736e093f7dd2e29b7974

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Aug 2020 20:29:30 -0700

I agree with David.  I don't see any way that the MDNS thing would make sense except in a very narrow domain (which WebRTC is).  Nothing stopping someone from defining an extension, of course.

No, this is general, but it is mentioned above.  I will add a reminder.

> The design of QUIC relies on endpoints retaining a stable address for the duration of the handshake. An endpoint MUST NOT initiate connection migration before the handshake is confirmed, as defined in section 4.1.2 of [QUIC-TLS].

Not sure if that is enough, as [this](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-9-2) is not directly a requirement, but more of an assumption.

I think that repetition will do.

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.

Yes, it acknowledges the problem, but this explicitly does not fix it (I don't know how you might read otherwise).  The SHOULD NOT exists to prohibit reactionary solutions that don't work.

Do you have a solution you would prefer?

I don't have anything concrete.  Any example would be hard to describe with anything other than "this person/organization did something really unwise".  Given the absence of a news-worthy example that would be easy to reference, this is really just a request to search for someone to shame.

I must be very confused, but your round trip point seems wrong.  The key point here is that the round trip is not safe, so any time you attempt that you are exposing services to a potential attack.  The point of this text is to describe heuristics that *might* block attacks without sending a packet at all.

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Aug 2020 20:30:04 -0700

a587bf000834d69e8898467c2e579ae4cdf63768  Mention ciphertext malleability

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3996/files/1cfbb7fdec57f73d8921736e093f7dd2e29b7974..a587bf000834d69e8898467c2e579ae4cdf63768

---

From: David Schinazi <[email-masked]>
Date: Mon, 31 Aug 2020 11:33:41 -0700

@DavidSchinazi commented on this pull request.

I'm not trying to shame anyone. I'm trying to ascertain whether this change is the right one: we're worsening the performance of the protocol (by requiring extra round-trips in some scenarios) and if the attack is purely theoretical then we shouldn't do that. Having a concrete example of actual harm would help motivate the performance degradation.

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

---

From: David Schinazi <[email-masked]>
Date: Mon, 31 Aug 2020 11:46:51 -0700

It's definitely possible that I'm the one confused. In my understanding, we have two ways of solving the "QUIC endpoint is sending attacker-controlled data to unvalidated address" issue:
1. the QUIC endpoint limits what it sends before validation
2. a magical network appliance verifies that the QUIC endpoint isn't sending evil packets where it shouldn't

I do agree with you that we want (1) instead of (2), but saying that (1) is more *efficient* than (2) isn't necessarily true if you measure efficiency as QUIC performance, because (1) can add a round trip but (2) doesn't

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

---

From: David Schinazi <[email-masked]>
Date: Mon, 31 Aug 2020 16:46:07 -0700

Huh. I just reread the paragraph, and now it I agree with you that it mentions the issue and warns against reactionary solutions. I guess I must have misread it last time around, apologies.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Aug 2020 23:43:42 -0700

7adbc31b00c3d26cff384bf66c88a5b72cc59722  This is not a true defense

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3996/files/a587bf000834d69e8898467c2e579ae4cdf63768..7adbc31b00c3d26cff384bf66c88a5b72cc59722