Re: [quicwg/base-drafts] Initials carrying different first ClientHello are considered as belonging to different connections (#2076)

[Christian Huitema <[e-mail]>]

huitema commented on this pull request.

This looks like a good idea, but it raises the question of how to handle HRR. I think that if we want to explore this path, we need to redefine a way to carry the HRR inside a stateless retry packet of some kind, so we can create two independent connections contexts if two client hello respond to a single HRR.

I am also not convinced that we can easily implement the client side of this. What if the attacker spoofs the response from server to client? Now the client receives to SHello, from the same address. What does it do?

> @@ -1037,8 +1037,18 @@ Servers MUST drop other packets that contain unsupported versions.
 
 Packets with a supported version, or no version field, are matched to a
 connection using the connection ID or - for packets with zero-length connection
-IDs - the address tuple.  If the packet doesn't match an existing connection,
-the server continues below.
+IDs - the address tuple, with the following exception.
+
+A server that uses a non-zero-length connection ID SHOULD handle Initial packets
+that share the same address tuple, Source and Destination Connection IDs, but
+contain different first ClientHello messages as belonging to different
+connections.  This might be used by a client to defend against attacks that race
+spoofed Initial packets with legitimate ones.  A server can treat every Initial
+packet containing a CRYPTO frame at an offset of 0 as potentially creating a new
+connection, discarding any packet that has the same Destination Connection ID
+and CRYPTO frame content as one that has been answered.
+

How do you distinguish between the first Initial packet and the next one, in the case of HRR? What if the server gets two responses to an HRR message, does it treat them as two connections?

I am concerned that to make this work, we should go back to the "stateless HRR" model, maybe sending the TLS HRR in a crypto frame in the payload of a retry packet.

-- 
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/2076#pullrequestreview-180636442