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

Kazuho Oku <notifications@github.com> Tue, 17 September 2019 17:16 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 E921A12008A for <quic-issues@ietfa.amsl.com>; Tue, 17 Sep 2019 10:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, 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 fqws4bWbpFmR for <quic-issues@ietfa.amsl.com>; Tue, 17 Sep 2019 10:16:10 -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 18983120044 for <quic-issues@ietf.org>; Tue, 17 Sep 2019 10:16:10 -0700 (PDT)
Date: Tue, 17 Sep 2019 10:16:09 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1568740569; bh=I+4cpYIg0JC85sfgqGYVWP7CrN+S+KGLpTngJK2d1h4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=zaN43Ke98n0JCtnEErMQk1gyQbO1f3nulGL0Q48XBKtmdKFsiVKooHKVdONCKY8c4 KZC1HwjIaZJUdCvjrcm2O+9+HaHEqLG87kP3Ov+QcNcZIrZWBh1b2i9vu5xQmzy/tw SH6cs/HfsoktK+yHAfqFoM/9kLZj1dyRQQ04l+f0=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6J2YJZMD7LNJOBPLN3RZDVTEVBNHHB26JPGY@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/c532315561@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_5d8114d9171aa_1b33fe4922cd95c26828"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/peSKVeJxj-POtq2Z_zgwBwSnhSk>
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: Tue, 17 Sep 2019 17:16:12 -0000

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