Re: [TLS] Narrowing allowed characters in ALPN ?

Christian Huitema <> Thu, 20 May 2021 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAB0E3A1C6E for <>; Thu, 20 May 2021 09:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id meGggDfOmx_c for <>; Thu, 20 May 2021 09:18:08 -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 1F2C13A1C71 for <>; Thu, 20 May 2021 09:18:07 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1ljlN6-0005cK-AV for; Thu, 20 May 2021 18:18:06 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4FmFJm6BC5z1v5M for <>; Thu, 20 May 2021 09:18:00 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1ljlN2-000747-O9 for; Thu, 20 May 2021 09:18:00 -0700
Received: (qmail 24792 invoked from network); 20 May 2021 16:17:58 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 20 May 2021 16:17:58 -0000
To:, Viktor Dukhovni <>
References: <> <> <> <> <> <>
From: Christian Huitema <>
Message-ID: <>
Date: Thu, 20 May 2021 06:17:59 -1000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5y+TdELUc3IPXxOn6N6uGoCj3CSdYahsEhiizd3WfZtEaqH s3QpfJ/DVNmy5D1srNXlYLLlWSy3OGfGBNeqx2anHyJxjDLo4/ugN15VVJm4KWrxEaaKeSxe0Wrx 6M4G5/Wm4Zd53xWOh54QqC5fJ2uRBBcQEUw8hF7V14kU31sZ2Vxh7hoyMoWHMkqYfQEaAmuJy6X4 RHGTlC379JhcfPNRpbt3W3gfNnuKkqGP09ZKLP25Cgscc2Nqd9azmDa4ZbYxn04qRLKGrOrEzQDq o2Fe5e0H1p2YD3fIDgqE3F/hSENKwnAR2oVisY+bnEqWCKi5klmK1va3wJScg92pg//jdNpXP/ul EV6DIUDLc0Yd6iTlYE+Zcn8p1rPpG64P1y7nVrUQfxkYoV3jt7fqlPgR0kaOEXLuWd+6zLg4wp8u X1nsyWu8Q0HDoORE+fy5gr3LgKffTIgl7nuGO/IJU1342OUMeHyTpNN0eXybX/w7/4a+Zyc1sUYl ckMDbruAhxfaTSRjFdfhbaOt3LLrhebQRRLiMmFEwVhLkOBp+oUwSqLRoaNz7BbY2+wvGxUYZKIH eB+jRC4XtIS/0RXQpaqOEnFzsC48bTEFY06/YbB87aZA2T1TDpm1DkXX6Es5zXntCB3G1CwpaI3Z 4ESkMWDVJEenxBoIht3V0nekAoxXArK43HgDYRF77p+EiFj+hbSyuLfHqAnAj7rgKH7+eCmmSJW8 IAP+/qadk9tHrSJtiVShcA6Xvva2QAVEjpqzANbJ1UfXmet2cbFKoyT/OdZLPuT3jSAGmqTcXvJ0 5fti5G0AuXq0T17woJo3avKeADIsy647Mn0zwmGzAi3Zn+YdthRNgs7Ig4l/XErpYn3glZTKFuaT l19W3ISq9+1KiLsESGU+y+fjdgjudZxiTPi+MG1QP35nsYfP84c+RFK3KiZuZ5OAUoGBziSYFLZu u6zX3xxsmqT8l9ARlsTalAaf
Archived-At: <>
Subject: Re: [TLS] 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 16:18:10 -0000

On 5/20/2021 5:28 AM, Viktor Dukhovni wrote:
> On Thu, May 20, 2021 at 11:23:15AM -0400, David Benjamin wrote:
>> SVCB's syntax would need us to not only exclude non-ASCII characters but
>> also avoid random delimiters like commas, right? I think that's going a bit
>> too far. As Ryan notes, complex definitions for allowed strings result in
>> ambiguities around who is responsible for validating what and subtle
>> variations in different implementations. That ambiguity can lead to
>> injection attacks when one component of a system expects some validation,
>> but the other component disagrees.
> Just the registry needs to be restricted.  TLS implementations would
> support all possible inputs.  HTTPS/SVCB would no longer need to parse
> complex quoted input formats.

Before the WG settles on restrictions, we may want to take a look at how 
ALPNs are used now, and what usage we can predict in the future. My 
personal experience is that they are used liberally. Application 
developers create protocols for a variety of reasons, such as the series 
of "h9-??" or "h3-??" protocols used in the QUIC WG, the "picoquic-test" 
ALPN used in the test suite of the "picoquic" implementation, the 
"picoquic-sample" ALPN used in the picoquic API samples, or the "doq-??" 
ALPN used to test DNS over QUIC.

All the examples I have seen in the wild are indeed ASCII strings, but 
then they come from English speaking developers. If my mother tongue was 
Chinese or Arabic, I might very well have picked non ASCII values. Very 
few of these end up registered with IANA. The registration is really 
useful when the application protocol is somehow standardized, with 
multiple implementations of clients and servers having to agree on the 
value. It is not required in practice when clients and servers are 
developed by the same organization, or by a closely cooperating set of 
organizations. The ALPN is whatever looks expressive to the developers 
and is unlikely to collide with other usage. The occasional collision 
would only be a problem if the same server was supporting multiple 
application protocols with colliding names.

So, maybe, peace and UTF8?

-- Christian Huitema