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

Kazuho Oku <notifications@github.com> Fri, 05 October 2018 02:30 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 DE4E8130DC2 for <quic-issues@ietfa.amsl.com>; Thu, 4 Oct 2018 19:30:10 -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 ec07HahDGYXK for <quic-issues@ietfa.amsl.com>; Thu, 4 Oct 2018 19:30:09 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5999412F295 for <quic-issues@ietf.org>; Thu, 4 Oct 2018 19:30:09 -0700 (PDT)
Date: Thu, 04 Oct 2018 19:30:08 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1538706608; bh=mO2Td38HDNOkMyelqzoNVRCKRN99SIEK3QmRQFFYR+I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=0M6DiZkXwjYPdraDBTKqSRaoQaJN9C1pmUjCOcKE3mHWv/i7mEfH0HncnvlHNeO3s Z25h2zDgXjkaTY4WRXc7BmpeTqKWOtPdiH4d763Yc7dPoJQLGI+7Rd4N+oc5erWuYK NvJYASqoSEyHrvTM14BbSArbVWl+MEHHeTmg35Xc=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab67febfeb90020c783f0a3e8ccb1db430296a708592cf0000000117ce8eb092a169ce15e0229d@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/427227807@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_5bb6ccb0529cd_6b303fd49c2d45b461736"; 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/6dBUsoQVDQ1aQ-PZd7apXNI2yuw>
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:30:11 -0000

@davidben 
> Another incarnation of this problem is if the client receives a huge window of CRYPTO frames into the future but not the first byte, so it can't process anything yet. With STREAM frames, we have flow control. With CRYPTO frames during the handshake, we know the handshake itself is bounded. Post-handshake, we don't know a priori the server won't send lots and lots of tickets.

I agree that the problem exists.

However, in my view, the memory exhaustion issue does not get resolved just by having a window for the CRYTO frames. My understanding that most TLS stacks buffers the octets of a handshake message until it receives a complete one. That means that the TLS stack is expected to buffer at most 16MB of junk even if we introduce window to the CRYPTO frames.

Considering that, I think it would be preferable to at first discuss introducing bounds for the TLS messages in the TLS working group, then consider how to apply that to QUIC. Until then, each QUIC stacks and TLS stacks can (continue to) have their own internal limits.

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