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

From: Kazuho Oku <[email-masked]>
Date: Thu, 29 Nov 2018 17:48:03 -0800

Based on https://www.ietf.org/mail-archive/web/quic/current/msg05093.html, implements countermeasures to prevent a man-on-the-side attacker disrupting the handshake by sending spoofed packets _to the server_.

The intent of the PR is to give the client (that is willing to pay the cost of complexity) the freehand to complete the handshake thereby establishing a connection even in the case where the attacker sends a spoofed packet to either of or both the endpoints.

Some notes:
* The PR says "SHOULD". This defense does not work for servers that uses zero-length CIDs, so I do not think we need to make it a MUST.
* The PR uses H(ClientHello) to distinguish connections instead of the alternative design suggested by @martinthomson to simply consider every Initial packet that contains a CRYPTO frame starting at offset zero as new connection. The reasoning is that we should better avoid creating multiple connection contexts on the server-side when the RTT is huge that a client sends multiple Initials.
* Adoption of #2053 is a prerequisite. We might want to change that PR to allow dropping individual frames rather than dropping per packet, because in the defense proposed here, the server's Initial that corresponds to the client's legitimate Initial might contain an ACK with an invalid PN. That happens when an attacker successfully races a spoofed packet with an identical CRYPTO frame but with a different PN.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2076

-- Commit Summary --

  * Initials carrying different first ClientHello are considered as belonging to different connections

-- File Changes --

    M draft-ietf-quic-transport.md (13)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2076.patch
https://github.com/quicwg/base-drafts/pull/2076.diff

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 29 Nov 2018 20:03:17 -0800

martinthomson commented on this pull request.

Let's make sure that the mailing list discussion is given time to consider this more fully.  I'm not convinced that it's a huge benefit, but this does allow a client to repair *some* of the attacks.  It doesn't protect the client if the server sends HelloRetryRequest, which remains a concern for me.  It helps the common case though, and that might be enough.

> @@ -1037,8 +1037,17 @@ 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, so that an attacker racing a spoofed Initial packet to the server

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

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 29 Nov 2018 20:30:49 -0800

@kazuho pushed 1 commit.

6bab251  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2076/files/c5d3b5f3cca4de8535193c767756e334bf1a2fcc..6bab25132693fc14c8b780197bb48c780540c509

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 29 Nov 2018 20:31:02 -0800

kazuho commented on this pull request.

Thank you for the suggestion. Applied.

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 30 Nov 2018 11:13:26 -0800

mikkelfj commented on this pull request.

It was also in the old text, but I'm not sure that term `address tuple` is clearly specified. What is meant is of course the source and destination port and IP pair. `tuple` is used elsewhere in two- and three-tuples.

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 30 Nov 2018 11:15:23 -0800

Generally this paragraph (also old text) use lower case `connection ID` while the next paragraph does not.

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 30 Nov 2018 19:17:44 +0000 (UTC)

+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.
+cannot disrupt the handshake.  The requirement can be met by remembering the

dangling sentence?

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 30 Nov 2018 11:23:21 -0800

Maybe this is a good approach but I'm not sure the exact approach is ideal.

If possible we should aim for a design that is not tightly coupled to TLS crypto content. We could for example add a nonce to the Hello and define that initial destination ID to be a specific well-defined hash of the Hello. The server then only needs to track the initial DCID but can verify incoming packets based on the hash. It is almost the same, but it gives the initial DCID more meaning.

If QUIC v.x does not use TLS, that version needs to make sure the initial DCID matches the critical signature of the first packet, which is then defined differently, but the mechanism remains the same. It might also be helpful to middleboxes?

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

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 30 Nov 2018 14:19:45 -0800

@kazuho pushed 1 commit.

6fd6e1f  word-wrap, remove trailing garbage

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2076/files/6bab25132693fc14c8b780197bb48c780540c509..6fd6e1ff16fdc5394ef56e0967e17a888eb8bc72

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 30 Nov 2018 14:22:11 -0800

Thank you for noticing that! Fixed.

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

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 30 Nov 2018 14:23:27 -0800

To me it seems that we generally use lower-case for talking about connection IDs, whereas we use upper-case for referring to certain fields (e.g. "Destination Connection ID").

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

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 30 Nov 2018 14:26:34 -0800

@mikkelfj That's a good point.

IMO, the proposed approach is not tied to TLS. Actually, it is tied to the following properties:
* only the contents of the CRYPTO frame affects the handshake
* all the client-side information necessary to derive a key can be found in the first Initial 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#issuecomment-443358423

---

From: MikkelFJ <[email-masked]>
Date: Fri, 30 Nov 2018 22:27:59 +0000 (UTC)

you are right, sorry

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

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 30 Nov 2018 14:30:30 -0800

:+1:

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 30 Nov 2018 14:35:15 -0800

`but
contain different first ClientHello messages as belonging to different
connections.`

This is TLS specific, but then QUIC v1 is TLS specific. I'm just wondering if we can make the text more generic without loss of purpose, and make the DCID more meaningful at the same time.

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