Re: [quicwg/base-drafts] Flow control for post-handshake CRYPTO messages (#1834)

Kazuho Oku <> Fri, 05 October 2018 03:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44D47126DBF for <>; Thu, 4 Oct 2018 20:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cLJDH98rs7I4 for <>; Thu, 4 Oct 2018 20:16:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB152130DC7 for <>; Thu, 4 Oct 2018 20:16:37 -0700 (PDT)
Date: Thu, 04 Oct 2018 20:16:36 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1538709396; bh=SrVx3OiMlRqguY2wGmg25qDl00vBQIlUri7J8cTjym8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dHn9EyfhPg7G7mdKaY87qfZl8GrUSFK1OFzSe2CfiemXeJxw1nSRigAX8D3NH7brH n0yLr9tAqfnZ9vPay9ksgjMPUBV7BcQRkmLE8iD7W+7rOfbHOOWgmL6f9ShbAi/w5l thWsVO1OQpAJ/ZzIgL7K2wHf3TgCUK7F3LMrpH44=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/1834/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Flow control for post-handshake CRYPTO messages (#1834)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bb6d794c4e86_1a083fb3fd2d45c4918f4"; 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
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Oct 2018 03:16:40 -0000

> Re the client Finished case, I guess that pulls in the mess of stuff around there. The spec is a little unclear what a server does in between server and client Finished. In particular, if doing 0-RTT the server needs to at least be willing to send half-RTT data. This text suggests that, since there's a binder, processing out of order is okay. (Unless I'm reading it wrong?)

Oh I missed it. Thank you for pointing that out.

> I agree that, if you believe the server just shouldn't process 1RTT packets before client Finished at all, the buffering issue is solved.

I had assumed that TLS stacks always expose the 1-RTT read key to the QUIC stacks acting as a server when it receives ClientFinished. I'd be curious to know if there are TLS stacks that takes an alternative approach.

> Though it does leave it unable to read the ACKs to half-RTT data which is differently weird. :-)

I assume that issue is unrelated to 0-RTT, right?

IIUC the advise to the QUIC stacks is that until you know that the peer can process a packet, you might want to coalesce the packet you send with another packet that uses a lower-epoch key; then you can have a _weak_ confirmation that the packet has reached the peer. Having such signal is beneficial to not give false information to the congestion controller though the loss recovery code needs to assume that the packet might have been lost, because a stack is allowed to drop a packet that is was unable to decrypt.

> I think the general post-handshake issue is probably the more isolated instance. They're the same problem in terms of buffering, but one has a confounding factor around whether it's actually an issue.

I agree. I think it is preferable to fix the issue.

Maybe I should rephrase my argument to that there should be limits in both layers (i.e. limit on the post-handshake message size in the TLS layer, and the window size in the QUIC layer, because having limit only on one layer does not prevent excessive buffering on the other layer. The two limits could either be a shared single value, two values shared using one extension, or two values shared using different mechanisms.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: