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

Nick Harper <notifications@github.com> Fri, 19 April 2019 21:57 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 9657E120493 for <quic-issues@ietfa.amsl.com>; Fri, 19 Apr 2019 14:57:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
X-Spam-Status: No, score=-8.001 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, SPF_PASS=-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 V0oLSRz3ji9E for <quic-issues@ietfa.amsl.com>; Fri, 19 Apr 2019 14:57:53 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B5E120487 for <quic-issues@ietf.org>; Fri, 19 Apr 2019 14:57:53 -0700 (PDT)
Date: Fri, 19 Apr 2019 14:57:51 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1555711071; bh=UPJaA/LhUEsW+5pQyoUe+3GTC8IPlQPsbAQAdaEgHBE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=EkIlxe+/WsR9v5JI/3yle+DhD9Ay4f1SsLX+OHZHPcnsJ/z0+P/qBVTuIeHqRts4K hJaVnuZxhqGCTMaNVXDrRRMP3Gq3UzrEl8cYjG7pkyLYICYiIDKtmXn5e1SYZCmhsw vNP25I57Tlf/BXq2gNzT2GX0+boTEHJLncNv5glQ=
From: Nick Harper <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZGZTR34OLEQYW3TA52Y53N7EVBNHHBSI2I34@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2524/review/228836047@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2524@github.com>
References: <quicwg/base-drafts/pull/2524@github.com>
Subject: Re: [quicwg/base-drafts] Specify behavior for post-handshake CRYPTO messages (#2524)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cba445fb6dfa_16a73ffb42ccd96816189e"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nharper
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/cUCyOVMJUyORUmeq-0nkZJyHmQg>
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, 19 Apr 2019 21:57:56 -0000

nharper commented on this pull request.



> +## Cryptographic Message Buffering
+
+Implementations need to maintain a buffer of CRYPTO data received out of order.
+Because there is no flow control of CRYPTO frames, an endpoint could
+potentially force its peer to buffer an unbounded amount of data.
+
+Implementations MUST support buffering at least 4096 bytes of data received out
+of order in CRYPTO frames. 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 a connection.
+
+Being unable to buffer CRYPTO frames during the handshake can lead to a
+connection failure. If its buffer is exceeded during the handshake, an endpoint
+can temporarily expand its buffer to complete the handshake. If an endpoint
+cannot expand its buffer, it MUST close the connection with a

I've changed this to "does not".

> +potentially force its peer to buffer an unbounded amount of data.
+
+Implementations MUST support buffering at least 4096 bytes of data received out
+of order in CRYPTO frames. 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 a connection.
+
+Being unable to buffer CRYPTO frames during the handshake can lead to a
+connection failure. If its buffer is exceeded during the handshake, an endpoint
+can temporarily expand its buffer to complete the handshake. If an endpoint
+cannot expand its buffer, it MUST close the connection with a
+CRYPTO_BUFFER_EXCEEDED error code.
+
+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

I didn't consider it potentially meaning further in the CRYPTO stream (I was thinking later in time). I've clarified that it means later in time.

Previously I had added language to state that if CRYPTO frames are being discarded, then the endpoint can tear down all crypto state that it has. I removed that since @martinthomson pointed out that's an obvious thing to do. I'm thinking that discarding any buffered but not processed crypto data falls under tearing down crypto state. If this no longer seems obvious, I'll add back that the endpoint can tear down crypto state and discard any remaining buffered crypto data.

-- 
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/pull/2524#discussion_r277099061