Re: [quicwg/base-drafts] Security Considerations text for a memory limit (#3004)

Kazuho Oku <> Wed, 04 September 2019 03:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DE4E12008A for <>; Tue, 3 Sep 2019 20:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.495
X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 53gdjzgbzCK3 for <>; Tue, 3 Sep 2019 20:58:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C71C0120072 for <>; Tue, 3 Sep 2019 20:58:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B8E202C1566 for <>; Tue, 3 Sep 2019 20:58:42 -0700 (PDT)
Date: Tue, 03 Sep 2019 20:58:42 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3004/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Security Considerations text for a memory limit (#3004)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d6f3672a9cb0_35f33fe873ecd95c1273d2"; 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: Wed, 04 Sep 2019 03:58:45 -0000

kazuho commented on this pull request.

> @@ -1126,6 +1126,13 @@ HTTP_QPACK_DECODER_STREAM_ERROR (0x202):
+While the negotiated limit on the dynamic table size accounts for much of the
+memory that can be consumed by a QPACK implementation, data which cannot be
+immediately sent due to flow control is not affected by this limit.
+Implementations MUST limit the size of unsent data, especially on the decoder
+stream where flexibility to choose what to send is limited.  If this limit is
+exceeded, the connection MUST be terminated.

I am not sure if "MUST terminate if the limit is exceeded" is a good advice, as there could be alternative strategies. For example, an endpoint can stop reading data from the streams, as well as giving the peer new stream ID credit while the amount of unsent data on the QPACK decoder stream is above some threshold.

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