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

Martin Thomson <notifications@github.com> Thu, 25 October 2018 04:37 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 8105912D4EE for <quic-issues@ietfa.amsl.com>; Wed, 24 Oct 2018 21:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.47
X-Spam-Level:
X-Spam-Status: No, score=-8.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 mCGWwYPAIqIZ for <quic-issues@ietfa.amsl.com>; Wed, 24 Oct 2018 21:37:03 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E638128CFD for <quic-issues@ietf.org>; Wed, 24 Oct 2018 21:37:03 -0700 (PDT)
Date: Wed, 24 Oct 2018 21:37:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1540442222; bh=soLNOvVfMCHwSUHcObI8n3ZabNJYAdpDH7yXIo8rIck=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ctse7Uez4FVWUgHSXPZM8Lupvrbta+JAEkoMXLlMd9xgCFlcp3gecMSBjwK2+efAl alPfK+Xz4NfEBE620FOuh2YhWLYvhIWVuLU+CQDdk5KkE2F81v/+xEGM/j1PHbonUc f+REwXTwfMelaDLcVSrIF+zSFxZEB18jbtCSRiSY=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab4870a46aee8ffa48da56571081fee206c6afe3e192cf0000000117e90a6e92a169ce15e0229d@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/432911920@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_5bd1486e97f4f_5eb33fbec14d45bc681959"; 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/7nHq-2C5LRPXMWQbYH5inXu172U>
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: Thu, 25 Oct 2018 04:37:06 -0000

I'm very much inclined to leave this "unfixed", but to leave a warning that sending large post-handshake messages risks connection failure.

> I had assumed that TLS stacks always expose the 1-RTT read key to the QUIC stacks acting as a server when it receives ClientFinished. I'd be curious to know if there are TLS stacks that takes an alternative approach.

That was what I had assumed too, until I thought through the nasty interactions with partial Handshake flights and 0-RTT.  That is, the TLS stack makes secrets available at the point that it would normally be installing them for its own use.  In that way, a server wouldn't install the 1-RTT read keys until it had processed the finished from the client, exactly as you say.

My current patch (which is still under review) releases secrets as soon as possible to avoid the problem where the server can't read Handshake acknowledgements because it is receiving 0-RTT.  The main consequence of that is that you need a separate API where the TLS stack tells the QUIC stack what it is willing to send and receive (well, I had a ton of fun fixing tests as well, but that's just because we were a little lazy with certain things in the past).

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