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

Nick Banks <notifications@github.com> Tue, 29 October 2019 14:06 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 6E436120018 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 07:06:32 -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 KpHbvMxVJ2E6 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 07:06:30 -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 C5E7712000F for <quic-issues@ietf.org>; Tue, 29 Oct 2019 07:06:30 -0700 (PDT)
Date: Tue, 29 Oct 2019 07:06:29 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572357989; bh=BxkasDkVfBRJanKH06tEXeaylIEtMK90C+u6SOattT4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=PU/QiPzeQ3qzGeNUxMYfAX/64lDDwGUjS+eHoXfYmhKYwso4B4XzIsMO6coqexpIz udbdb+gtwyrivNUvR9DYZS4aWgjbznt6lPJdhCz9JH6yCbCb29YHDMT02KljXtI7ya 0ApcNoLCO90f7p1RpkXmwEzEQujpFyLONJCwJ7ak=
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5W3272D2JMPQGCUA53YWD7LEVBNHHB5FU4AM@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/547436840@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_5db84765a00ae_6d923f8dec6cd96447827"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/BDM7ep728wMMzxiCPCGkYfYlckY>
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: Tue, 29 Oct 2019 14:06:32 -0000

@kazuho 

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

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.

> There is. The case is where there is an error in the 0-RTT data that the client sends, and the server responds with a CONNECTION_CLOSE frame. In this case, there is no ambiguity on the server-side, as the server has committed to processing a particular application protocol. However, there is an issue on the client-side. The client cannot tell which application protocol has been selected, as the CONNECTION_CLOSE frame (carried in either Initial or Handshake) may arrive before it receives the Encrypted Extensions handshake message that carries the name of the negotiated protocol. We can say that a server sending an application-level close before the client sends an 1-RTT packet is an alternative way of negotiating the protocol. But are we really going to say that? I think it's too complicated.

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.

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