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

martinduke <> Fri, 17 April 2020 18:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CE303A134C for <>; Fri, 17 Apr 2020 11:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.175
X-Spam-Status: No, score=-2.175 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_16=1.092, 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 TsTbTQJlo8h5 for <>; Fri, 17 Apr 2020 11:18: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 271713A1340 for <>; Fri, 17 Apr 2020 11:18:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E72DD6A10F9 for <>; Fri, 17 Apr 2020 11:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1587147481; bh=iTQPEzZggWdPW/VanyADNKixi4/euerzjWOkEL7Cd4c=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=R6uStNOlP4YcOD3EdvhdtW4yCigL03pFS8Qki7xxNk9DeHAyBodsogA9+fZkcWwfi MrWR1xPerTrpgT/Q+XqyV54sCCo/lbxKve5XMLIerLC/plyaGaiGbbevT2j2wQkfV8 dCghtt49cfIdwMyjAw6oZt9EGMb0cqqe4mnS1Y9k=
Date: Fri, 17 Apr 2020 11:18:01 -0700
From: martinduke <>
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_5e99f2d9d59aa_72ce3f95824cd964322518"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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: Fri, 17 Apr 2020 18:18:06 -0000

I agree that the normative requirements are fine. It would be good to expose the specific ALPN error, and we can make the necessary TLS change to detect this properly.

However, "generic TLS alerts" are a user-configurable setting, and we're reluctant to just override customer preference just because it's in a CONNECTION_CLOSE instead of a TLS Alert.

Moreover, when the TLS WG gets around to encrypting the ALPN, it is not clear that exposing this error is so benign anymore.

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