Re: [quicwg/base-drafts] TLS alert no_application_protocol is not always possible (#3580)

Kazuho Oku <> Thu, 16 April 2020 23:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D82DE3A130C for <>; Thu, 16 Apr 2020 16:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9Osrob0-vxay for <>; Thu, 16 Apr 2020 16:16:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 247E53A130A for <>; Thu, 16 Apr 2020 16:16:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1AB6B26164B for <>; Thu, 16 Apr 2020 16:16:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1587078988; bh=X5KgWt1ZWd3+sw0g8zLHwzULD0R1un1LoTEmBHQjkbI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gc8xnyrOjO4OfdM9DTvv2IHmfgokEL3/ud4kZA37hATmCuDaRXeUEYF4RshY5SIGk A7pJvD6fSLyHoYyUJ/T+mV/7y9zmVUTV4bmJuu3An7FCO4QkQHs9a0YgbZAn/p0GWI 2J4LljGjEnCuSzHPBYKxhi8A2ft/a4IkF/d57DPk=
Date: Thu, 16 Apr 2020 16:16:27 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3580/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] TLS alert no_application_protocol is not always possible (#3580)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e98e74bc9a4b_65a23f86e86cd960712fd"; 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
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Apr 2020 23:16:31 -0000

@martinthomson I think the problem is due to how certain implementation handles ALPN.

In case of H2O, we handle ALPN in our _on_client_hello_ callback, that is invoked by picotls ( At this point, the call stack is H2O (application) -> quicly (QUIC stack) -> picotls (TLS stack) -> _on_client_hello_ (application callback).

In this type of design, if the TLS stack is going to determine the error code (or change the error code returned from a callback), then it would be impossible (or difficult) for the QUIC stack to send the appropriate code.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: