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

From: Christian Huitema <[email-masked]>
Date: Mon, 03 Dec 2018 07:28:43 +0000 (UTC)

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 03 Dec 2018 17:57:45 -0800

kazuho commented on this pull request.

Yeah the text that discusses the approach purely by referring to the CRYPTO frame is hard to understand (and it might be erroneous).

The logic I'd expect the stacks to have is something like below:
```
if crypto_frame.offset == 0:
  ch_hash = sha256(crypto_frame)
  if conn_is_open():
    if open_conn.handshake_key != nil:
      if open_conn.ch_hash != ch_hash:
        handle_as_new_connection()
      else:
        handle_packet_with_care()             // to be addressed in #2045, #2053
    else:
      handle_initial_as_part_of_connection()  // HRR case
  else:
    handle_as_new_connection()
```

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

I do not think so, because our experience in TLS 1.3 tells us that HRR will rarely be used, because the endpoints are incentivized to avoid the additional round-trip imposed by HRR.

-- 
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#discussion_r238506402

---

From: Christian Huitema <[email-masked]>
Date: Wed, 05 Dec 2018 19:29:07 -0800

In the mailing discussion, I mentioned that "_I understand how to create a separate connection context on the server for each different incoming server hello... but I am concerned that this solution breaks if the client needs to send multiple different Initial messages, such as a new Client Hello in response to an HRR, or an ACK._" @kazuho replied that HRR would be very rare in practice and thus not a worry, and that "_Regarding ACKs, you need to potentially ignore or postpone applying them. The same goes for CONNECTION_CLOSE._" But this PR does not say any of that. If we want it considered, then it needs to explain how the processing of ACK and CONNECTION_CLOSE frames is modified for Initial packets. It also need to explain how HRR are handled. That cannot be just a handwave.

-- 
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#issuecomment-444736092

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 05 Dec 2018 20:35:26 -0800

@huitema I agree that the specification should clarify how ACK and CONNECTION_CLOSE needs to be processed. Though to clarify, my assumption has been that the handling of packets containing invalid frames is being discussed in #2053.

-- 
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#issuecomment-444745498

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Dec 2018 22:38:51 -0800

Closing based on discussion on the list.  I think that we have better ideas.

-- 
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#issuecomment-446858962

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Dec 2018 22:38:52 -0800

Closed #2076.

-- 
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#event-2023391396