Re: [quicwg/base-drafts] Application close should be disallowed in Initial or Handshake (#3158)

Kazuho Oku <notifications@github.com> Wed, 30 October 2019 05:50 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 B9A69120044 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 22:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_HELO_NONE=0.001, 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 AWFDF38zO6rR for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 22:50:27 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3496A12003E for <quic-issues@ietf.org>; Tue, 29 Oct 2019 22:50:27 -0700 (PDT)
Date: Tue, 29 Oct 2019 22:50:26 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572414626; bh=lM0wPFQC/qAW7w9ZEs8IWLpZOQmwtjYbq2776PzXHJ4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=oeLlViruCxFfytjqkH3g8I4XoGM3WWkYtFpmjq7SUS8bJNoapFAcJOmHNlutsErr4 BRVZ5AeWZDNhxfAJAt24cdq8uGIPeyjjuKucQINTYaXoBxii62cavYM9EtcbgMS7qe qa/t0kXBXtK6T98dOZ9/P++tFlHgq/60gGyfHeUI=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5LHCCTSGRV64SKQ6N3YZLSFEVBNHHB5FU4AM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3158/547748333@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3158@github.com>
References: <quicwg/base-drafts/issues/3158@github.com>
Subject: Re: [quicwg/base-drafts] Application close should be disallowed in Initial or Handshake (#3158)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db924a25dd27_71743fe15c2cd96810326b"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/7iLWA47gbvFaZgEKTR5VS5Gs9H4>
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 Oct 2019 05:50:29 -0000

@nibanks 
>> The problem is that then there would be two requirements:
>> * Application protocols MUST define a generic error code that can be exposed unencrypted.
>> * QUIC stacks need to provide an API that tells the application if a CONNECTION_CLOSE frame is going to be sent using Initial packets. Each application needs to consult that in order to determine the error code to be sent.
> 
> For the first bullet, that's a decision for the application protocols.

At the very least, the transport draft needs to suggest that, otherwise an application protocol might leak information through APPLICATION_CLOSE frames carried in Initial packets.

> For the second, I'd argue you don't need any special API. If the app terminates the connection before the "handshake complete" notification then any error code it would pass down to the QUIC API would not be sent in a 1-RTT packet. That state is enough for the app to make an intelligent decision. Another option is to have an API flag that indicate the application close is allowed to be send unencrypted.

Requiring such interaction seems more complicated than just forbidding the use of APPLICATION_CLOSE in Initial and Handshake packets in favor of CONNECTION_CLOSE(user_canceled). How a QUIC stack enforces that is an implementation issue, but for example, when an application instructs the QUIC stack to close the connection, the stack can decide which of the two frames to send based on the current state.

> If you assume this is not the common case, then I don't think we need optimize for it. The app just closes the connection after the handshake completes.

I'd dispute that this is an optimization. This is about addressing a security concern that we have so far left open.

-- 
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/3158#issuecomment-547748333