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

Nick Harper <> Thu, 20 May 2021 23:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 444A53A0EC1 for <>; Thu, 20 May 2021 16:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8_1PDY0JW6QR for <>; Thu, 20 May 2021 16:15:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CBEB83A0EC0 for <>; Thu, 20 May 2021 16:15:39 -0700 (PDT)
Received: by with SMTP id n61so6067558uan.2 for <>; Thu, 20 May 2021 16:15:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WHCGG7EB9RiamkMkjOma+oce7BF8uQuOXzpLM250/wI=; b=bmTb5heSMEo0wHUUybqFnFu+NOnK1JXE1GhB93KartVf/LcOs2HnYT2JtTHrycINKo ttu/rXmK7YV2sxdxVGeQCMV7Zvi360PllVBWNchC++J4Mk8c/Rmaaruv/g181SEfucwQ cDo7tTWjRA5dvx2PTqkh5/1yy+YajsNRDqRnFeUoddcoZHnW6YO1EjrHDuW4pI7c23Od PrI5NcAchni/LQHyhOkitDhxqtz/jH4kskyIolPJCpnwi+4vk5umXYDzisdJ/yXaRinu HcqZSAStEPzcLB4lONPysHDBEKrkzStBdNy/BckODPhw9GqE6BfB8I/l7VGFJsGoHAdZ onKg==
X-Gm-Message-State: AOAM533CsfXZ6/UyMonN2AdQs15zHQuXvWeaHI5PvBUj5RNl9JQ5lblb PrIxaJqbCFKpEJ0KsgWG+ha5SoZI4TYKZ6EhDsUGCS1gg7nxt1imCLk=
X-Google-Smtp-Source: ABdhPJytISiv+Gz7SqSIgtrdrCiobjx8L+DKYY+/KoY7dMRcXR7N020ur9Ij9flkH7CYnFw9F13wSP5cHLptz7KnGDM=
X-Received: by 2002:ab0:36b4:: with SMTP id v20mr6980459uat.67.1621552538035; Thu, 20 May 2021 16:15:38 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <YKbo/>
In-Reply-To: <YKbo/>
From: Nick Harper <>
Date: Thu, 20 May 2021 16:15:27 -0700
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000003bc2505c2cb1fed"
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:15:44 -0000

On Thu, May 20, 2021 at 3:56 PM Viktor Dukhovni <>

> I agree it is a straight-forwarding encoding for machines, and it is
> well suited for the GREASE code points.
> 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.

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. Those solutions should be favored over restricting the wire
protocol/code point allocation.