Re: [TLS] Narrowing allowed characters in ALPN ?

[Christian Huitema <[e-mail]>]

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