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

[Mike Bishop <[e-mail]>]

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

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

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

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