IETF Logo Mail Archive

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

martinduke <notifications@github.com> Fri, 17 April 2020 18:18 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 5CE303A134C for <quic-issues@ietfa.amsl.com>; Fri, 17 Apr 2020 11:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.175
X-Spam-Level:
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: 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 TsTbTQJlo8h5 for <quic-issues@ietfa.amsl.com>; Fri, 17 Apr 2020 11:18:04 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271713A1340 for <quic-issues@ietf.org>; Fri, 17 Apr 2020 11:18:04 -0700 (PDT)
Received: from github-lowworker-c73936b.ash1-iad.github.net (github-lowworker-c73936b.ash1-iad.github.net [10.56.112.13]) by smtp.github.com (Postfix) with ESMTP id E72DD6A10F9 for <quic-issues@ietf.org>; Fri, 17 Apr 2020 11:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; 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 <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2V6MXTOYTBGCABIFF4UXJ5TEVBNHHCHP77D4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3580/615392681@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3580@github.com>
References: <quicwg/base-drafts/issues/3580@github.com>
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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/BwZm3qXaSDbGNUDxgEjzRETm4aY>
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: 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:
https://github.com/quicwg/base-drafts/issues/3580#issuecomment-615392681

v2.23.0 | Report a Bug | By Email