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

Martin Thomson <> Thu, 16 April 2020 23:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB5A63A13AB for <>; Thu, 16 Apr 2020 16:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.721
X-Spam-Status: No, score=-1.721 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_20=1.546, 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 52mt9kB8FQ9q for <>; Thu, 16 Apr 2020 16:47:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 598043A13AA for <>; Thu, 16 Apr 2020 16:47:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6215FA0050 for <>; Thu, 16 Apr 2020 16:47:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1587080850; bh=ZC+b9vhAObUFmr+Pqo6LLeMeFNFTdp5nNhwmDFnL1So=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=HeJeDirTJfOMuixosK0QiYgEYwfhtTnqAq6CQfmH/7wzMgbifWdFG9/KCiNU9YQO2 Hx+lUtEfZrVtuR9q9zqpZo878Qj++kiDW42rmo9L2HP783/sPGL6AGnifBxgMeJlaD O4WfGatNBGnp/Agv5v9XH0k5W/gJhYyxdGjNaaT8=
Date: Thu, 16 Apr 2020 16:47:30 -0700
From: Martin Thomson <>
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_5e98ee9251d62_5a943fdd802cd95c10684c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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:47:33 -0000

I see.  I hope that the application isn't the callback code, but that quicly is involved in this somehow; otherwise, you have just made H2O responsible for fulfilling QUIC requirements that you might assume quicly would be responsible for.

In general, I would assume that you have access to QUIC transport state in your callback from the TLS stack.  Let's say that you choke on the ALPN.  You cause TLS to issue a generic alert (which is fine, as Lucas points out).  At some later point that alert is going to hit QUIC code again so that it can be translated to a QUIC alert.  If you can save the reason from the callback (presumably you need this capability to save transport parameters) then you can construct the right message.

Of course, that's complicated.  The generic alert is fine.

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