Re: What to do when ALPN negotiation fails?

"Martin Thomson" <mt@lowentropy.net> Mon, 04 March 2019 23:06 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D887131130 for <quic@ietfa.amsl.com>; Mon, 4 Mar 2019 15:06:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=o9DhtQnT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sUtNRild
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 OZC4hMbVT7yy for <quic@ietfa.amsl.com>; Mon, 4 Mar 2019 15:06:20 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E58131103 for <quic@ietf.org>; Mon, 4 Mar 2019 15:06:20 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 20B89231AD for <quic@ietf.org>; Mon, 4 Mar 2019 18:06:19 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 04 Mar 2019 18:06:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type; s=fm1; bh=AYh4vN8gpidV+jtoolUtRT3y9e+QHK1BCfxWRE/ wCLA=; b=o9DhtQnTxzuS467nRIM000vBrY96/axfGZ5k/O565qsDxsmLP9ZEoB8 2CkTgmQPud83D9am223T9Q2J5/YbyIDZo6YNEIdcI/qP7xSuVxEzjL9Ln8r9lvul clGZammv5K9Z5c7v+mjXuBzUrsJRxvfT5spJVi1/9JtLGsK2DdGmYz/pfOmpSFLD jFMqDugykAAxTKDMf5HYh2QibzQyk3KbfmnSvXCtN0FVG2ITklQjwvcZvEaNGN0N KAKgkzpDwVnOawJsj7Yyf1aCnD0E/HQPYftUUmoscb54G70U9sts6mpaJiNWXAia kISLBR+W09e7ie52HzuCgcHP4kvSw5g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=AYh4vN8gpidV+jtoo lUtRT3y9e+QHK1BCfxWRE/wCLA=; b=sUtNRild6qUhK6M+Yi86DzD4hcCYcr1l0 4uoYrJhilwVfpEkkCEQl2WGsPkdIL1ECO32EY2G0RgTYFiglba9TferNsnWfNjKb 3y/0Lb8avZ6PNzRIHFzaRD2Usviwd/qGlN/XoHVItDgYzv7FdRiEJ9ZKYkRY/s1L m9yx6DtzZu22kzXRM3GikWua6++J4S5qLEGGMZ3EiGQ2uh6W9wHo7NtzuHQzRONo e18OSc+LfHdBAnTcpjBZTv7Hf9F/hkNLEEXe3xxrcU5/DB0bYqOr8RAq36PJKAf9 /6HEgTy3dqb74RKLgKPWlMZIjmkygDaviZIHLc6om0/B5fnL2cW/A==
X-ME-Sender: <xms:aq99XMSescVyZ_vwe267avGJ7tb_kbJEV5KvY4rSVMwKeBphNfwkSA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfedvgddthecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfgjfhffhffvufgtsehttdertd erredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigv nhhtrhhophihrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd
X-ME-Proxy: <xmx:aq99XGMyhPkY1ivZMmLHnWPa3mO0NdZWrAITaQV3fPDVofueFyC2FQ> <xmx:aq99XBGxsFoCMxfmiMkyQ4zMnsWPjx6H0et5KcNbPYcMGxiU4Hq_hw> <xmx:aq99XGjGURNP2UfDq3mQHrRcazI67belfQNUuqDTp9u-Zn_gFuRwng> <xmx:a699XLMYvNj-WZ0V2MrewBKpAdG_Ue1flUHSm1E266vt5y4nYKjCFA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7E6CE7C3AB; Mon, 4 Mar 2019 18:06:18 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5
X-Me-Personality: 92534000
Message-Id: <66dbdb15-53cd-4618-89f5-99fd9be9ce7e@www.fastmail.com>
In-Reply-To: <20190304152418.GA22305@mandy.flat11.house>
References: <20190304152418.GA22305@mandy.flat11.house>
Date: Mon, 04 Mar 2019 18:06:19 -0500
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: What to do when ALPN negotiation fails?
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/dsQWAqceNynTqz7c3ZSqiEGhpno>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2019 23:06:23 -0000

This seems like the right plan to me.

As much as it is awkward to go outside of the ALPN rules here, what you need to realize is that ALPN presumes a setting where failure to negotiate ALPN is the pre-existing default.  No so with QUIC, and in fact, we've recently decided to require ALPN.  Requiring ALPN as we do avoids a bunch of mess related to cross-protocol attacks, which we agree is a fine thing.

On Tue, Mar 5, 2019, at 02:26, Alessandro Ghedini wrote:
> Hello,
> 
> PR#2314 added a requirement for end-points to close a connection if the ALPN
> negotiation fails, but it doesn't say which error needs to be used.
> 
> RFC7301 says:
> 
>   In the event that the server supports no protocols that the client advertises,
>   then the server SHALL respond with a fatal "no_application_protocol" alert.
> 
> So it seems to follow that QUIC servers would have to send a 0x1XX error with
> whatever value the no_application_protocol alert has.
> 
> However RFC7301 only defines server behaviour (since in TLS ALPN is not
> mandatory), but it doesn't forbid clients to send that alert either, and for
> QUIC's purposes it seems better to use the same error on both sides.
> 
> Anyway, all of this to say that I created an issue to clarify all this [0], and
> written up a PR [1] that makes both sides send the no_application_protocol
> alert.
> 
> Thoughts?
> 
> Cheers
> 
> [0] https://github.com/quicwg/base-drafts/issues/2495
> [1] https://github.com/quicwg/base-drafts/pull/2483
> 
>