Re: [TLS] Recommending ALPN / backwards compatibility Sat, 08 May 2021 09:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20CF93A4510 for <>; Sat, 8 May 2021 02:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KhZ_BXsIxWuF for <>; Sat, 8 May 2021 02:11:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48F9B3A450E for <>; Sat, 8 May 2021 02:11:13 -0700 (PDT)
Received: from (localhost. []) by (MeTA1-1.1.Alpha16.0) with ESMTPS (TLS=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256, verify=OK) id S00000000000582DB00; Sat, 8 May 2021 11:11:11 +0200
Received: (from ca@localhost) by ( id 1489BBG7014374 for; Sat, 8 May 2021 11:11:11 +0200 (CEST)
Date: Sat, 08 May 2021 11:11:11 +0200
Message-ID: <>
References: <> <> <> <> <> <0f9101d73d89$a3f252e0$ebd6f8a0$> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
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 09:11:16 -0000

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?

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"?

Maybe it would be useful to specify an "empty"/"dummy" protocol,
which just states case 2, e.g., "NOMATCH"?

Address is valid for this mailing list only, please do not reply
to it direcly, but to the list.