Re: [quicwg/base-drafts] Clarify what to do when ALPN negotiation fails (#2495)

Kazuho Oku <notifications@github.com> Thu, 07 March 2019 01:10 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 721B11310F9 for <quic-issues@ietfa.amsl.com>; Wed, 6 Mar 2019 17:10:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
X-Spam-Status: No, score=-8.001 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_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 PZqpA4NNeZY7 for <quic-issues@ietfa.amsl.com>; Wed, 6 Mar 2019 17:10:49 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B23126D00 for <quic-issues@ietf.org>; Wed, 6 Mar 2019 17:10:49 -0800 (PST)
Date: Wed, 06 Mar 2019 17:10:48 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1551921048; bh=AhRh0zNcpttR0Ax5N/reEDtunpASp1QUD5KYytW/n4Y=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=BKZBtHiPU5xRVl/cE1Degm2I801rY/pRj37FQYz/WcLLjsIHEUawIRpH1qrImo5V6 5v5y+S5GcSwP1ytVrXqLlVb/2ExCFv3axq5xST5ZYkT2CCvo+FAzPDtnmXjU4nt7Sj cVnei8BJM4lw8LFkGfJkTQjMJKn6KcsY8+OHUNhM=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab771f960d0774753912d34473acafc933baaa3e1692cf000000011898319892a169ce18d8ac2b@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2495/470341990@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2495@github.com>
References: <quicwg/base-drafts/issues/2495@github.com>
Subject: Re: [quicwg/base-drafts] Clarify what to do when ALPN negotiation fails (#2495)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c806f985448f_544d3fd4694d45b811892c"; 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/G_L--j5ZqEEnIioys3_MCFpzdUg>
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, 07 Mar 2019 01:10:51 -0000

My :+1: goes to making the change, though I would like to confirm that it wouldn't be illegal for a client to close the connection with `no_application_protocol` error _after it sends ClientFinished_.

I ask this because depending on the design of the TLS stack, the QUIC stack might not be able to see the result of ALPN before the TLS stack generates a ClientFinished (note that EE.ALPN and ServerFinished might arrive in one packet).

It's my understanding that the intent of the issue is to not allow the client to send any application data on ALPN failure. Assuming that's true, sending the alert after ClientFinished should be fine.

-- 
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/2495#issuecomment-470341990