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

Mike Bishop <notifications@github.com> Wed, 09 October 2019 17:55 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 0F03B120A65 for <quic-issues@ietfa.amsl.com>; Wed, 9 Oct 2019 10:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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] 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 oCF02y1sQcdR for <quic-issues@ietfa.amsl.com>; Wed, 9 Oct 2019 10:55:30 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD848120A58 for <quic-issues@ietf.org>; Wed, 9 Oct 2019 10:55:29 -0700 (PDT)
Date: Wed, 09 Oct 2019 10:55:29 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1570643729; bh=X3fmV1FFGsFjCADnRmHMnRoPxLe0hpkFq8e5n7+KSgo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VqcdaTV0JkdQZKDXLd/g+NEHu9JxjBWXTy1ayhS6CwWmKPvWdJX0h/9bqFHITvlgF aMivCpkDASF9IuHwFXmz9iMFhJbEDCniWZoTsyTKUaMBFUtQEp1KDBy4fY///quKsV XR4QT1XgYi5vDKRQB/ksBkk9OvX/EuEAHKcr8TgA=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYAJ3HUJFHI4ER3BNV3VNP2BEVBNHHB26JPGY@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/299589290@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_5d9e1f111cbe1_61a33f8c836cd960773ea"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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/k9S9ErSVc8W68vVW6KGyIiYbtlA>
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, 09 Oct 2019 17:55:32 -0000

MikeBishop commented on this pull request.

The text of this PR looks good. I share the concern about whether we want to support multi-packet ClientHello messages, though the discussion (which should be on the issue, not the PR) seems fairly convincing that we'll need to do this at some point if we don't do it now.

> @@ -570,11 +570,16 @@ 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 contains the start or all of 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

Or address tokens, presumably?

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