Subject: [quicwg/base-drafts] Allow ClientHello to span multiple QUIC packets (#3045)

From: David Schinazi <[email-masked]>
Date: Tue, 17 Sep 2019 01:35:54 -0700

The restriction for ClientHello to fit in a single UDP datagram was added back when the retry mechanism was more tightly coupled to the TLS crypto. At this point, the restriction doesn&#39;t get us much, and is preventing us from running some post-quantum experiments.

Fixes #2928.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Allow ClientHello to span multiple QUIC packets

-- File Changes --

    M draft-ietf-quic-tls.md (27)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3045.patch
https://github.com/quicwg/base-drafts/pull/3045.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/3045

---

From: Marten Seemann <[email-masked]>
Date: Tue, 17 Sep 2019 01:45:35 -0700

marten-seemann commented on this pull request.

> @@ -565,11 +565,19 @@ older than 1.3 is negotiated.
 
 ## ClientHello Size {#clienthello-size}
 
-QUIC requires that the first Initial packet from a client contain an entire
-cryptographic handshake message, which for TLS is the ClientHello.  Though a
-packet larger than 1200 bytes might be supported by the path, a client improves
-the likelihood that a packet is accepted if it ensures that the first
-ClientHello message is small enough to stay within this limit.
+The first Initial packet from a client starts with its first cryptographic
+handshake message, which for TLS is the ClientHello.  Servers might need to
+parse the entire ClientHello (e.g., to access extensions such as Server Name
+Identification (SNI) or Application Layer Protocol Negotiation (ALPN)) in order
+to decide whether to accept the new incoming QUIC connection.  If the
+ClientHello spans multiple Initial packets, such servers would need to buffer
+the first received fragments, which could consume excessive resources if the
+client's address has not yet been validated.  To avoid this, servers MAY use

The resources are consumed either way, but if the client's address has not yet been validated, a server might not be willing to commit those resources.

> -cryptographic handshake message, which for TLS is the ClientHello.  Though a
-packet larger than 1200 bytes might be supported by the path, a client improves
-the likelihood that a packet is accepted if it ensures that the first
-ClientHello message is small enough to stay within this limit.
+The first Initial packet from a client starts with its first cryptographic
+handshake message, which for TLS is the ClientHello.  Servers might need to
+parse the entire ClientHello (e.g., to access extensions such as Server Name
+Identification (SNI) or Application Layer Protocol Negotiation (ALPN)) in order
+to decide whether to accept the new incoming QUIC connection.  If the
+ClientHello spans multiple Initial packets, such servers would need to buffer
+the first received fragments, which could consume excessive resources if the
+client's address has not yet been validated.  To avoid this, servers MAY use
+the Retry feature (see Section 8.1 of {{QUIC-TRANSPORT}}) to only buffer
+partial ClientHellos from clients with a validated address.  Though a packet
+larger than 1200 bytes might be supported by the path, a client improves the
+likelihood that a packet is accepted if it ensures that the first ClientHello

s/is accepted/isn't dropped while in transit/

-- 
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/3045#pullrequestreview-289105392

---

From: Nick Banks <[email-masked]>
Date: Tue, 17 Sep 2019 06:41:27 -0700

This proposed changes imposes some new, nontrivial requirements on the server side. As a server, would I be required to support multi-packet client initials? Do we **really** need this in V1?

-- 
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/3045#issuecomment-532226068

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 17 Sep 2019 07:21:31 -0700

I share @nibanks's concern:  The pain in the ass would be quite real.  Is post-quantum crypto in scope?

-- 
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/3045#issuecomment-532243299

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Sep 2019 09:06:14 -0700

@nibanks 
> As a server, would I be required to support multi-packet client initials?

I'd point out that endpoints are already required to support muti-packet client Initials when the TLS handshake uses HRR. Therefore, IMO the PR does not add new threats.

-- 
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/3045#issuecomment-532288795

---

From: Nick Banks <[email-masked]>
Date: Tue, 17 Sep 2019 09:16:48 -0700

HRR is not stateless (at the QUIC layer) though, correct? The client's first packet still must completely contain ALPN and (optionally) SNI. That information is used by WinQuic to decide initially if the connection should be accepted and more server resources commit to processing the connection. Adding another point to the QUIC layer to decide if Retry is needed is additional work.

-- 
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/3045#issuecomment-532292790

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Sep 2019 09:38:41 -0700

@nibanks I might argue that this PR does not prevent you from using the ALPN and SNI in the first packet as a way to "skip" Retry. In that hack, the difference between the status quo and this PR is that an incomplete CH in the first packet becomes a signal to send a Retry rather than an error. I do not think it adds complexity.

Considering the fact that we can remove other complexities due to the 1-packet restriction, this PR is a good simplification.

-- 
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/3045#issuecomment-532301058

---

From: Nick Banks <[email-masked]>
Date: Tue, 17 Sep 2019 10:01:36 -0700

I'm not arguing that this PR would require loads more code, but I definitely don't agree that it's a "good simplification" of the current design. This adds additional attack surfaces that must be analyzed and implementations ensure they have adequate defense.

Again, I ask is this absolutely required for V1? What chartered requirements for QUIC deem this change necessary for V1?

-- 
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/3045#issuecomment-532309839

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Sep 2019 10:16:09 -0700

At the moment, a QUIC stack is required to indicate to the TLS stack that the CH should be constructed in a way that invokes HRR (by omitting the key_share extension), if the CH is otherwise going to not fit in one packet. This requirement is not only complex but also imposes one additional roundtrip (when the rule is invoked).

Regarding the charter, we are tasked to create a protocol that minimizes connection establishment latency, while having "security and privacy properties that are at least as good as a stack composed of TLS 1.3 using TCP." We already have post-quantum extensions proposed for TLS 1.3, it is my understanding that Chrome is already doing experiments. They require use of CH that do not fit in single packet, which, without resolving this issue, imposes complexity and one extra round-trip. Considering these aspects, I might argue that we are _encouraged_ by the charter to resolve the problem :-)

-- 
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/3045#issuecomment-532315561

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Sep 2019 18:18:07 -0700

martinthomson requested changes on this pull request.

There is [text in the transport draft](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#packet-initial) that needs updating as well.

I think that acceptance and loss are two separate things and what we're talking about here is acceptance.  The predicate on the statement is that the path supports packets of that size.  This is speculating about a server's willingness to buffer the ClientHello bytes.

To that end, this isn't about the 1200 byte minimum MTU, it's about making the ClientHello *as acceptable as possible*.  Fragments are immediately less acceptable, and while smaller fragments are easier to hold, what matters is the size of the entire message, because that's the upper limit on what the server might have to buffer.  Non-fragmented ClientHello can be as large as the path will support, because the server doesn't have to save them.

I think that we can strike this last sentence and things will be clearer.

 

```suggestion
partial ClientHello messages from clients with a validated address.  Though a 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/3045#pullrequestreview-289624058

---

From: MikkelFJ <[email-masked]>
Date: Tue, 17 Sep 2019 22:20:52 -0700

Regardless of post-quantum and HRR, I agree with @nibanks that it is problematic to commit multiple packets before any kind of validation. If that is already the case due to HRR, I hope there is a way to avoid that without relying on client generated content. Otherwise the server is wide open to slow loris connection attacks.

As to post-quantum - fine to have an experimental setting - in a real post-quantum world, perhaps min MTU can be larger?

-- 
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/3045#issuecomment-532522918

---

From: Christopher Wood <[email-masked]>
Date: Thu, 19 Sep 2019 15:10:00 -0700

chris-wood commented on this pull request.

Related to "as acceptable as possible," should we try to recommend a minimum bound on fragments? (I'm reminded of data dribble, even though that's a different problem entirely.)

-- 
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/3045#discussion_r326404096

---

From: MikkelFJ <[email-masked]>
Date: Thu, 19 Sep 2019 15:15:20 -0700

mikkelfj commented on this pull request.

If this multiple packet initial thing lands, at least we should limit the packet count / time to arrival or provide guidance. Dribble (slow loris) can happen in fragments or just in many very small complete packets over a very long 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/3045#discussion_r326405445

---

From: David Schinazi <[email-masked]>
Date: Tue, 24 Sep 2019 10:24:14 -0700

@DavidSchinazi pushed 1 commit.

c2c7abb67e8dc7ba6e41d124e3ea85338ae2ab21  MT review comment

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3045/files/7af6d612244fb2056eea105620eba01d7ed9dc73..c2c7abb67e8dc7ba6e41d124e3ea85338ae2ab21

---

From: David Schinazi <[email-masked]>
Date: Tue, 24 Sep 2019 10:30:36 -0700

@DavidSchinazi pushed 2 commits.

3ae146dffc74a4533f1388dbabd0aabb971fe973  Merge branch 'master' into multi_packet_client_hello
c1eeb6e354fe569fb2d8d624e4691bf495814401  MT review comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3045/files/c2c7abb67e8dc7ba6e41d124e3ea85338ae2ab21..c1eeb6e354fe569fb2d8d624e4691bf495814401

---

From: David Schinazi <[email-masked]>
Date: Tue, 24 Sep 2019 10:32:34 -0700

0a2645f4754df3d63a32e85e9bef9f4f3aed1278  Another MT review comment

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3045/files/c1eeb6e354fe569fb2d8d624e4691bf495814401..0a2645f4754df3d63a32e85e9bef9f4f3aed1278

---

From: David Schinazi <[email-masked]>
Date: Tue, 24 Sep 2019 10:35:29 -0700

DavidSchinazi commented on this pull request.

Given that servers are encouraged to send Retry packets to clients with multiple-packet ClientHellos, this change doesn't make dribble worse, an attacker can send a single-packet ClientHello then start its SlowLoris without this change.

-- 
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/3045#discussion_r327744308

---

From: MikkelFJ <[email-masked]>
Date: Tue, 24 Sep 2019 11:11:33 -0700

You don't need to commit as much memory after that point.

-- 
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/3045#discussion_r327761253

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 Sep 2019 16:39:17 -0700

martinthomson approved this pull request.

Some residual singular/plural disagreements.

-Note that if the server sends a HelloRetryRequest, the client will send a second
+Note that if the server sends a HelloRetryRequest, the client will send another
 Initial packet.  This Initial packet will continue the cryptographic handshake

```suggestion
series of Initial packets.  These Initial packets will continue the cryptographic handshake
```

-Note that if the server sends a HelloRetryRequest, the client will send a second
+Note that if the server sends a HelloRetryRequest, the client will send another
 Initial packet.  This Initial packet will continue the cryptographic handshake
 and will contain a CRYPTO frame with an offset matching the size of the CRYPTO

```suggestion
and will contain CRYPTO frames starting at an offset matching the size of the CRYPTO
```

>  Initial packet.  This Initial packet will continue the cryptographic handshake
 and will contain a CRYPTO frame with an offset matching the size of the CRYPTO
-frame sent in the first Initial packet.  Cryptographic handshake messages
-subsequent to the first do not need to fit within a single UDP datagram.
+frame sent in the first Initial packet.

```suggestion
frames sent in the first flight of Initial packets.
```

-- 
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/3045#pullrequestreview-292763064

---

From: David Schinazi <[email-masked]>
Date: Tue, 24 Sep 2019 17:15:50 -0700

c2d175f315c819e57cdfd59d7544c6cdef56721c  MT suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3045/files/0a2645f4754df3d63a32e85e9bef9f4f3aed1278..c2d175f315c819e57cdfd59d7544c6cdef56721c

---

From: David Schinazi <[email-masked]>
Date: Tue, 24 Sep 2019 17:20:14 -0700

da7b436e37cc2a23712c6c0ae40488592e7e33c2  reflow

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3045/files/c2d175f315c819e57cdfd59d7544c6cdef56721c..da7b436e37cc2a23712c6c0ae40488592e7e33c2

---

From: ianswett <[email-masked]>
Date: Fri, 27 Sep 2019 12:19:48 -0700

ianswett approved this pull request.

Some minor nits, but the core content looks good.

> @@ -570,11 +570,16 @@ older than 1.3 is negotiated.

```suggestion
The first Initial packet from a client contains the start or all of its first cryptographic
```

> @@ -589,12 +594,9 @@ QUIC transport parameters, and other negotiable parameters and extensions could
 cause this message to grow.
 
 For servers, in addition to connection IDs and tokens, the size of TLS session
-tickets can have an effect on a client's ability to connect.  Minimizing the
-size of these values increases the probability that they can be successfully
-used by a client.
-
-A client is not required to fit the ClientHello that it sends in response to a
-HelloRetryRequest message into a single UDP datagram.
+tickets can have an effect on a client's ability to connect efficiently.
+Minimizing the size of these values increases the probability that they can be
+successfully used by a client.

This second sentence now seems out of place, since it's unclear why clients wouldn't be able to use them?

> @@ -3959,16 +3950,15 @@ Initial packet containing other frames can either discard the packet as spurious
 or treat it as a connection error.
 
 The first packet sent by a client always includes a CRYPTO frame that contains
-the entirety of the first cryptographic handshake message.  This packet, and the
-cryptographic handshake message, MUST fit in a single UDP datagram (see
-{{handshake}}).  The first CRYPTO frame sent always begins at an offset of 0
-(see {{handshake}}).
-
-Note that if the server sends a HelloRetryRequest, the client will send a second
-Initial packet.  This Initial packet will continue the cryptographic handshake
-and will contain a CRYPTO frame with an offset matching the size of the CRYPTO
-frame sent in the first Initial packet.  Cryptographic handshake messages
-subsequent to the first do not need to fit within a single UDP datagram.
+the start of the first cryptographic handshake message.  The first CRYPTO frame

```suggestion
the start or all of the first cryptographic handshake message.  The first CRYPTO frame
```

-- 
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/3045#pullrequestreview-294515748

---

From: David Schinazi <[email-masked]>
Date: Fri, 27 Sep 2019 16:15:37 -0700

9951381007ee865c62fe411de213ad0162648f7d  Merge branch 'master' into multi_packet_client_hello
55695427d3604f12b8c92144c9f1fceb2b770d22  Review comments from Ian

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3045/files/da7b436e37cc2a23712c6c0ae40488592e7e33c2..55695427d3604f12b8c92144c9f1fceb2b770d22

---

From: David Schinazi <[email-masked]>
Date: Fri, 27 Sep 2019 16:15:45 -0700

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/3045#discussion_r329279353

---

From: David Schinazi <[email-masked]>
Date: Fri, 27 Sep 2019 16:15:53 -0700

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/3045#discussion_r329279370

---

From: David Schinazi <[email-masked]>
Date: Fri, 27 Sep 2019 16:16:00 -0700

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/3045#discussion_r329279384

---

From: ianswett <[email-masked]>
Date: Fri, 27 Sep 2019 19:27:34 -0700

-- 
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/3045#pullrequestreview-294616800