IETF Logo Mail Archive

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

David Benjamin <notifications@github.com> Fri, 05 October 2018 02:45 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 4B9D3130DC9 for <quic-issues@ietfa.amsl.com>; Thu, 4 Oct 2018 19:45:23 -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, 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: 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 YjTaRfjja-c0 for <quic-issues@ietfa.amsl.com>; Thu, 4 Oct 2018 19:45:21 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52833130DC2 for <quic-issues@ietf.org>; Thu, 4 Oct 2018 19:45:21 -0700 (PDT)
Date: Thu, 04 Oct 2018 19:45:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1538707520; bh=apwg0Re7O0ncFBdNmoYSg24bQ40tTu2a2y1hRlZI6Ws=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Nxt10nl5xPvJhZbCoemd9tjssFlK8c7z+A7ODuUh9qgc4x5PD+i0nQhXjHWdMVKON KkGGUOd3J1iZtvHDnhyO9e8Rqp4+T2WjF+hMAT1OulORyhV2pCHdplxjXWBiTJK5hT ySxY9U0bpoRuHSNqkJcp2QBWCk1G6bnYPACuJRg8=
From: David Benjamin <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab6710df5c96deee400717366c1dd2b0a001ed3bec92cf0000000117ce924092a169ce15e0229d@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1834/427230016@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1834@github.com>
References: <quicwg/base-drafts/issues/1834@github.com>
Subject: Re: [quicwg/base-drafts] Flow control for post-handshake CRYPTO messages (#1834)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bb6d0407c341_50503fafdb2d45b8898f3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: davidben
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/Z6X65UyYZCk3ErLWIMi3H4f9DBI>
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: Fri, 05 Oct 2018 02:45:23 -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?)
https://tools.ietf.org/html/draft-ietf-quic-tls-15#section-5.7

I agree that, if you believe the server just shouldn't process 1RTT packets before client Finished at all, the buffering issue is solved. Though it does leave it unable to read the ACKs to half-RTT data which is differently weird. :-)

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.

-- 
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/1834#issuecomment-427230016

v2.23.0 | Report a Bug | By Email