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

Kazuho Oku <notifications@github.com> Tue, 29 October 2019 04: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 70D63120046 for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 21:50:00 -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 99CGj1io3kL5 for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 21:49:58 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF27120043 for <quic-issues@ietf.org>; Mon, 28 Oct 2019 21:49:58 -0700 (PDT)
Received: from github-lowworker-c53a806.ac4-iad.github.net (github-lowworker-c53a806.ac4-iad.github.net [10.52.23.45]) by smtp.github.com (Postfix) with ESMTP id 303836A01F4 for <quic-issues@ietf.org>; Mon, 28 Oct 2019 21:49:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572324597; bh=AWfPOuag1eOeKq9eHrqpabvpDd5+hJhoqj9RddaYY9k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bLq3tJ28QyJknfgRuIUSUJYKMlspvZ0l5/QYx7V8+Jax8fru2Nn4aMysoN4Nzz8XB JN5QzLDTE18PFgDcc6+WUUoPL6tgpzL6jt9oRP0o8rOWEh51pxfJE4X9p8nzaF3N/u BJab+qmiR8Z7XbKsjp8nKCBsuceitoZsul9ZLqnA=
Date: Mon, 28 Oct 2019 21:49:57 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4H2FRRFJ5Z6OKZ6JF3YT3XLEVBNHHB5FU4AM@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/547254865@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_5db7c4f52157d_12023fdf642cd96c9784"; 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/lqR2KzUb-ub1O0Z9W0Nzv9zlfKs>
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 04:50:00 -0000

@nibanks Thank you for checking.

> Things may be difficult in some scenarios, but we can leave the decision on how to handle things up to the application layer.

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 0-RTT scenario, you can use a generic application error code. There's no ALPN ambiguity there, right, since they have to use the same one as previous?

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.

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