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

Martin Thomson <notifications@github.com> Wed, 18 September 2019 01:18 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E35412007A for <quic-issues@ietfa.amsl.com>; Tue, 17 Sep 2019 18:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spxUrYa9JIP8 for <quic-issues@ietfa.amsl.com>; Tue, 17 Sep 2019 18:18:08 -0700 (PDT)
Received: from out-17.smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BEBB12012D for <quic-issues@ietf.org>; Tue, 17 Sep 2019 18:18:08 -0700 (PDT)
Date: Tue, 17 Sep 2019 18:18:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1568769487; bh=TOyPAqGAz6NFzAwr3C85XOcGuXr2w3O1OUytZzBHrpM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=KyqMvcjPbsp6A2D/XpWvvQN21UqCT/wkcTEjLBWT5PCJKYFCS9Gh1TH/c7HEElU1E d20+V5Q9Uen56J9vj68Cmj+bJ9nWwY6/29t4lwP7gPjzZI/I4d6QQ0ujVVEwyZt4NM Tz2MN4SAebpWctROqyKqsvSjHU0HuJRSjeRz+rq0=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2I55OM5UD5MKVJQFF3R2VD7EVBNHHB26JPGY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3045/review/289624058@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3045@github.com>
References: <quicwg/base-drafts/pull/3045@github.com>
Subject: Re: [quicwg/base-drafts] Allow ClientHello to span multiple QUIC packets (#3045)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d8185cf4379d_53da3f82dbacd9681074e9"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/EMhqZLpmlnrVdJlAla8xvfne1zc>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Sep 2019 01:18:14 -0000

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.

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

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.

> @@ -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 Retry feature (see Section 8.1 of {{QUIC-TRANSPORT}}) to only buffer
+partial ClientHellos from clients with a validated address.  Though a packet

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