Re: [TLS] [EXTERNAL] Re: Narrowing allowed characters in ALPN ?

Viktor Dukhovni <> Thu, 20 May 2021 23:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F84B3A0FDB for <>; Thu, 20 May 2021 16:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5ZH8rG_dyanJ for <>; Thu, 20 May 2021 16:23:15 -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 46CDE3A0FCF for <>; Thu, 20 May 2021 16:23:15 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 5B4AAD476A; Thu, 20 May 2021 19:23:14 -0400 (EDT)
Date: Thu, 20 May 2021 19:23:14 -0400
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <YKbo/> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] [EXTERNAL] Re: Narrowing allowed characters in ALPN ?
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: Thu, 20 May 2021 23:23:22 -0000

On Thu, May 20, 2021 at 04:15:27PM -0700, Nick Harper wrote:

> > But, it makes for a fairly terrible user interface for the human
> > operator.  Compare:
> >
> >     * managesieve
> >     * 6d616e6167657369657665
> >
> > Typos in hex values are easy to make and hard to recognise.
> I agree that it's not a great user interface for the human. A good
> solution to that is to let the user define a constant with the hex value
> (or build the ALPN constant into the config language), like how with
> OpenSSL one can specify "ECDHE-ECDSA-AES128-GCM-SHA256" instead of 0xC02B.
> Using your example, one could define a constant ManageSieve = {0x6d 0x61
> 0x6e 0x61 0x67 0x65 0x73 0x69 0x65 0x76 0x65} and reference that constant,
> and if a typo were made (e.g. one put ManageSeive in the config), the
> config would fail fast, vs if one configured "manageseive" as the ALPN
> directly, the typo would propagate further through a deployment before
> being detected/fixed.

The constants would work fine in programming APIs, but they're of no use
in filling in DNS records in web forms, master copies of zone files, ...
or any other configuration file syntax where the context supports only

> There are good solutions to solve the human factors of managing/configuring
> ALPN that don't require imposing restrictions on what ALPN can go on the
> wire in TLS.

Note, I am NOT promising restricting what can go on the wire TLS, only
what can go in the IANA ALPN registry as a standard interoperable ALPN

> Those solutions should be favored over restricting the wire
> protocol/code point allocation.

None come to mind for the alpn field of the proposed HTTPS/SVCB records.
What would you suggest?  (I hope not hex).

The current proposal, even with the rather compex quoting/escaping rules
is better than hex, but is rather fragile.  Developers will get it
badly wrong.