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

Martin Thomson <notifications@github.com> Wed, 30 January 2019 02:09 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 660C41310DA for <quic-issues@ietfa.amsl.com>; Tue, 29 Jan 2019 18:09:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Level:
X-Spam-Status: No, score=-12.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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 y2fCzapPoVTU for <quic-issues@ietfa.amsl.com>; Tue, 29 Jan 2019 18:09:51 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4481310CD for <quic-issues@ietf.org>; Tue, 29 Jan 2019 18:09:50 -0800 (PST)
Date: Tue, 29 Jan 2019 18:09:49 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1548814189; bh=TPHRdwIAa+JMqpHzZ4KpdYNYG8QlTgLlhsuo8k5Y7OY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XOjhIEi4O+1LNVHtXwa1/RN68FjGojX5++ZQx7KZnFlNB6njfUK8DUHG23Tz9vkpK wwHQ0PRqM90ZhXR8OwbFpstzusOO/QujaU8CxaXAlwgH7A5TvaC1cUFxiR+XV0tMPG FS8+aNebEYOe7qptYKJeNSz+dVnVvjTtofYMZxaI=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab7079c1368f81fdb3e545129319c764e898925c0492cf000000011868c96d92a169ce15e0229d@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/458783852@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_5c51076dcf3bf_32aa3f97c40d45bc1915fb"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/WH8JumM4V1IGJxBafFnO1e0AiM0>
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: Wed, 30 Jan 2019 02:09:52 -0000

The problem here is that CRYPTO is not flow controlled.  Endpoints can cause arbitrary buffering of CRYPTO frame data.

This has very little to do with the handshake (though @siyengar notes that we have a similar concern for CRYPTO in Initial and Handshake, that is bounded by the handshake timers).

Proposal is to allow endpoints to maintain a buffer of any size they choose.  If they receive a TLS message that does not fit into that buffer, they can drop all subsequent TLS data.  The effect of this is to disable TLS from that point onward.  Currently, we don't depend on this frame for anything other that NewSessionTicket, for which loss has no real consequence.

We will assign a minimum buffer size that implementations are required to support, probably something small like 4k.  A higher limit is possible.  If an endpoint finds that this buffer is overrun they MAY discard all CRYPTO frames with higher offsets, or they MAY drop the connection with a `NEW_ERROR` code.

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