Re: [quicwg/base-drafts] Disallow changes of table size after 0-RTT (#2276)

Martin Thomson <notifications@github.com> Sat, 12 January 2019 00:05 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 A1FA8126BED for <quic-issues@ietfa.amsl.com>; Fri, 11 Jan 2019 16:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Level:
X-Spam-Status: No, score=-12.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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_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 Pa95tSBbozCG for <quic-issues@ietfa.amsl.com>; Fri, 11 Jan 2019 16:05:20 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF0A128AFB for <quic-issues@ietf.org>; Fri, 11 Jan 2019 16:05:20 -0800 (PST)
Date: Fri, 11 Jan 2019 16:05:19 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1547251519; bh=WlO69g00ZUV9yiJOeNT9i4O6OEB+4CrW396hfX/hkEI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=FKy8JNlnFbIY7/3NS5CgaRkzonP1JnUAr+nevDT/17Vsv+Gsny/pKCLYdVOa0rkHX shyOmuOAblEWrY7Ka2av3AgtvDCEtxCkBMAB9u7VMa8cXAaU8ef4JyVMmnf/7xXdb+ ruza7OWJOQMXuCUPesYOma7gCd0GEN6xgC0afDIw=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab6ee41aa235da22be335af0cc56fc4e2378dca31892cf000000011850f13f92a169ce1789f586@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2276/453696458@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2276@github.com>
References: <quicwg/base-drafts/issues/2276@github.com>
Subject: Re: [quicwg/base-drafts] Disallow changes of table size after 0-RTT (#2276)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c392f3f314ce_3d9b3fb11d6d45bc753a9"; 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/y_sc4FX6lABBLbLG1fy2oZ8LhMY>
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: Sat, 12 Jan 2019 00:05:22 -0000

If we allow 0 to become >0, that isn't fundamentally that different to allowing increases. If you chose 0, then 0-RTT probably isn't that effective either. I am inclined to leave no change as the only option if we go this way.

The alternative is to prohibit wrapping until SETTINGS is received, which I agree is manageable, but a little clumsy. For me, this comes down to whether we think that changing max capacity will be that common. It might be easier to say that changes (increases really) can't be made until you get a full handshake.

We see only slightly more than 1% of our TLS 1.3 connections accepting 0-RTT - or even attempting it. It is early days for 0-RTT, but that suggests that there will be plenty of opportunities - even for a server that prefers 0-RTT - to bump the capacity limit.

-- 
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/issues/2276#issuecomment-453696458