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

Andrew Macedonia <> Thu, 16 April 2020 15:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EF3C3A0ADA for <>; Thu, 16 Apr 2020 08:09:05 -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 xhwvoxa39leq for <>; Thu, 16 Apr 2020 08:09:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1DAC43A0AD1 for <>; Thu, 16 Apr 2020 08:09:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2F72E8C1EDF for <>; Thu, 16 Apr 2020 08:09:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1587049743; bh=r4UzWCIFSKWpD4etXozEzT3PXuBsDgeF914qBnXmfz0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VSMjXKyDeoUH1CJWlqV/7cA++SZmNqvmleXsDUodaiZLDha/4AvKz76SxoyoLfTse /JVvKiER0vnufjbTEZpnV69u0RLOov90PEWwVyP43jwXklJQcMQh8Q+enkbzyZqLjx tdtb8v0b/Vl3dRFrHBOUnOEkwOUmP8mZcVJVDfyw=
Date: Thu, 16 Apr 2020 08:09:03 -0700
From: Andrew Macedonia <>
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_5e98750f1f7aa_22803fd6ab0cd96c115617"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ajmacedonia
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 15:09:05 -0000

I'm referring to the error code field in the QUIC CONNECTION_CLOSE frame. In the case of a crypto error, the QUIC error code for handshake failure is 0x128. The QUIC error code for no application protocol is 0x178. The draft mandates that we send 0x178.

In our stack, TLS does the ALPN parsing and if there is a TLS alert, QUIC converts it to a CONNECTION_CLOSE with the reported error code; TLS alert 0x28 for handshake_failure, 0x78 for no_application_protocol. Due to TLS converting all alerts during the handshake to handshake_failure, we end up sending a QUIC CONNECTION_CLOSE frame with 0x128, instead of 0x178.

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