Re: [quicwg/base-drafts] Specify behavior for post-handshake CRYPTO messages (#2524)

Kazuho Oku <> Fri, 05 April 2019 00:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0C2E1202C3 for <>; Thu, 4 Apr 2019 17:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.002
X-Spam-Status: No, score=-8.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 wIj3jZuW31VT for <>; Thu, 4 Apr 2019 17:45:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1CF3120090 for <>; Thu, 4 Apr 2019 17:45:19 -0700 (PDT)
Date: Thu, 04 Apr 2019 17:45:18 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1554425118; bh=QHfXkXdiYkElmFFzJ/q0YjsbCUphw+SZ+68ItgucIcs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=i+Iqbx8poKbWXS6qxP94lmifHPMfkkeGLkRj28nbQNEqZUIkFELvPptuoA1PYPlX1 9NGhqRsy5W7DC85kcAEipPt1tgQXC9k9ZX/aR/AoVrr3fmAh53wlVOTsjnbkEEB0tF TTaWGd1KLVXz0qT0273aD/DD6PXvCYz0mSTDGLl0=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2524/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Specify behavior for post-handshake CRYPTO messages (#2524)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ca6a51e5bcbe_5a063fcb5c8d45c069123"; 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 Apr 2019 00:45:22 -0000

kazuho commented on this pull request.

> +potentially force its peer to buffer an unbounded amount of data.
+Implementations MUST support buffering at least 4096 bytes of data received in
+CRYPTO frames out of order. Endpoints MAY choose to allow more data to be
+buffered during the handshake. A larger limit during the handshake could allow
+for larger keys or credentials to be exchanged. An endpoint's buffer size does
+not need to remain constant during the life of the connection.
+Being unable to buffer CRYPTO frames during the handshake leads to a connection
+failure. If an endpoint's buffer is exceeded during the handshake, it can expand
+its buffer temporarily to complete the handshake. If an endpoint cannot expand
+its buffer, it MUST close the connection with a CRYPTO_BUFFER_EXCEEDED error
+Once the handshake completes, if an endpoint is unable to buffer all data in a
+CRYPTO frame, it MAY discard all subsequent CRYPTO frames, or it MAY close the

Because TLS handshake messages require a stream that guarantees in-order delivery. Once you discard some bytes, you cannot use subsequent data on the stream. Therefore, the only way to keep the connection open after discarding some bytes is to discard all the following bytes, while sending ACKs.

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