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

[ekr <[e-mail]>]

@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