Re: [TLS] Recommending ALPN / backwards compatibility

Filippo Valsorda <> Sat, 08 May 2021 13:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E8CA3A16F8 for <>; Sat, 8 May 2021 06:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=3TVzggdB; dkim=pass (2048-bit key) header.b=EMFombiX
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SNbjMAYFl5Iv for <>; Sat, 8 May 2021 06:26:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F84F3A16F4 for <>; Sat, 8 May 2021 06:26:37 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 6EC011361 for <>; Sat, 8 May 2021 09:26:32 -0400 (EDT)
Received: from imap1 ([]) by compute3.internal (MEProxy); Sat, 08 May 2021 09:26:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=niPD/HZnWaFlTw3etkNwpXodtOu3ece Dr8t7hPxIFm8=; b=3TVzggdBTHy/JDEDrjotK9rq8IUdk3Iz7Kei3wuU+BWtszN hdg1XQQgnxGtZm8p/wp7bAWpJvD6NuF/o3uw4nns5w/pfnC+M0CEBHls2iHlbVbV N2aYseQxI+VDjFieLvgyCxeyQXJiIacsHh53qkK1lVTIduqyWpacmiYku+g2JYpR mGFgQfRXeFhfszM/kiajfph/u9ztawzHbHBFGFey94pFGFixdKRLDPgPZDYNSm6O udvO6UfyfUspbq5cNemC8jj4O9n25+Vxbj1x4veadwE8ZSU/ykiRe2y8drE+wDNH czpEnVK0TcRWhdYH3Lo6xohCj6C5CyA3vhxW1VQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=niPD/H ZnWaFlTw3etkNwpXodtOu3eceDr8t7hPxIFm8=; b=EMFombiXPscmqPX6u6/RUT AYv8DVaFq4M36i1XDdYimjZCHxDH2ODXTU5KrYIT0HyHGtqBXn0DxOANv4ZnVvHE ZmqCVfxuOcshq+rdJWc4k5GXFviZnmti1GhKdJ7a1DnV+/l8sM2i5Mwhzq2n2P+/ 3x5CCXx+VjDw+ypjT2riAXBMmV0Y037pjgx5Z6c5zuD8ZKwAHfmVFIsUmzbu8SIH Gt5qAuZOQ5mgV+A9M2GPxZq2UvFrLk26wJa8HkqxcDjk8PgJFUHK4DpM311diliF eGMThdvDP2LhOD+brOlsj1vONHp57TUwkhSdomWjvGi477zeT5H6vy3eTwhT45WA ==
X-ME-Sender: <xms:h5GWYLGsmuG4W7jnYS4chlczruIN5iYLpI5MW3u41brYOTmMuSKq_Q> <xme:h5GWYIWpJP81R6qduAy7XeIxtOaZgkO1MStk6QrAKCBRmjoWHqfWTAq3aDTbyPTso K9jXQL_jFQoTqSSJw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeggedgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfhfhilhhiphhpohcugggrlhhsohhruggrfdcuoehfihhl ihhpphhosehmlhdrfhhilhhiphhpohdrihhoqeenucggtffrrghtthgvrhhnpeegtdevle eftdejkeeflefgieegudeiudellefgvefgkeeikeeitdelffekkeeutdenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehfihhlihhpphhosehmlh drfhhilhhiphhpohdrihho
X-ME-Proxy: <xmx:h5GWYNID5iY5eY9olUtibJwjXkOukHhj0EJyODqKq1dQkntunoJnPg> <xmx:h5GWYJG42R39vXfeqJEwix-pv__c1X-T4GjvSU2d8Kiuigb_t6ZzBg> <xmx:h5GWYBWgdXFAlPoQ3pvWJi3ajJhy2CCfurWSjW1L2aesHE55vD8WDg> <xmx:iJGWYJicF5dIz4DYKvRjGCck9dhnGzb1Pidyz8eFYYt9hmuNp8zwBQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 850DA130005F; Sat, 8 May 2021 09:26:31 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <> <0f9101d73d89$a3f252e0$ebd6f8a0$> <> <>
Date: Sat, 08 May 2021 09:26:10 -0400
From: Filippo Valsorda <>
Content-Type: multipart/alternative; boundary="6953dfb334144fe0a898404ffebb50fc"
Archived-At: <>
Subject: Re: [TLS] Recommending ALPN / backwards compatibility
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 08 May 2021 13:26:44 -0000

2021-05-08 05:11 GMT-04:00 <>:
> On Fri, Apr 30, 2021, Martin Thomson wrote:
> > An existing application protocol might not have been assigned an
> > ALPN identifier.  For other protocols the ALPN identifier might
> > not have been part of the original protocol definition, or use of
> > ALPN might have been defined originally as being optional.
> Sorry for this stupid/simple question but I cannot find a way for
> a client to determine whether a server
> 1. does not support ALPN.
> 2. supports ALPN but did not select a protocol.
> It seems it is only possible to return a selected protocol,
> not am "empty" protocol to indicate case 2, correct?

My understanding (and the Go implementation) is that a server running an application without ALPN does not support ALPN, so it will ignore the extension (even if the TLS stack does have code to handle it).

A migration would work like this: if the client updates before the server, the client will send ALPN but it will get ignored by the server, which doesn't support ALPN yet; if the server updates before the client, the client will not send ALPN, which the server will allow (because the no_application_protocol condition is "the server supports no protocols *that the client advertises*"). Once they both updated, the server is expected to close the connection if the client sent an ALPN extension without the right protocol in it, otherwise we lose most of the cross-protocol benefit of ALPN in the first place.

> IMHO this would be useful for backwards compatibility/ migrating a
> protocol to support ALPN.  RFC 7301 states the server "SHALL" abort
> in this case:
> 3.2.  Protocol Selection
> ...  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.
> but that might not be a good way to support migration, which probably
> is why is just "SHALL" not "MUST"?

SHALL means MUST per RFC 2119. It's unfortunate we use a word that sounds like SHOULD to mean MUST, but that's a requirement, not a suggestion.