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

[David Schinazi <[e-mail]>]

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

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

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

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

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.

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

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

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

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