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

[Kazuho Oku <[e-mail]>]

@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