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

Ryan Sleevi <> Thu, 20 May 2021 17:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABD333A0EBF for <>; Thu, 20 May 2021 10:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Dw5XLhnvSut0 for <>; Thu, 20 May 2021 10:46:51 -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 7FA093A2022 for <>; Thu, 20 May 2021 10:46:51 -0700 (PDT)
Received: by with SMTP id d16so12896136pfn.12 for <>; Thu, 20 May 2021 10:46:51 -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=SS5Gi3Sov2QnAOg9dq2g7wQxXvJg+nr3PDv2CHuVMJY=; b=mduFDEWUDNaT6//5IiJRWJl7q8FP0sJRamUPBhcsNc87OYap1nbDKuCEEVrcU4u0oF TwAZh6BiMDKgVaTm4RisKkIcus4OkjujUBCd42nlzalr2DfUaW9zVAwCzEghkosHlPzG wTgBv79lD769fDMlpc8LG6fN9WwKsS+PUxssEow1f8kjDO1vuyzq2xrqs/aXRe0SNiCv Tu/t7VqIygE2PLb5r0FT2pu5q6xZA1+g0u8VYg83L/tb/Sm162egge+zZdU1hagu3W7E buMVxqn+oAIC9tkLK7CScR1L/2v8tnMf3Ir3r+XyHQ/r8k+MX9MfvY4/EyfA5rMHnQ38 jjZA==
X-Gm-Message-State: AOAM532/RCz32T09e80v+1/Qbhczcc51TdVUXGYh8OKES9rSexbi4/hD 7ed3AeQ6f1Mdej90mSZF6K3ovLTCSxs=
X-Google-Smtp-Source: ABdhPJyjr3ChYp9O6rMD/1JmpwLZXYir3QxOR0OpErFAcFYMrNRP8jESClGP5FEbH06WJgdDDiuznA==
X-Received: by 2002:aa7:9f8f:0:b029:2dc:76bc:edce with SMTP id z15-20020aa79f8f0000b02902dc76bcedcemr5620816pfr.29.1621532810358; Thu, 20 May 2021 10:46:50 -0700 (PDT)
Received: from ( []) by with ESMTPSA id m19sm2519790pjq.41.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 May 2021 10:46:50 -0700 (PDT)
Received: by with SMTP id n6-20020a17090ac686b029015d2f7aeea8so5858016pjt.1 for <>; Thu, 20 May 2021 10:46:50 -0700 (PDT)
X-Received: by 2002:a17:90a:2ec6:: with SMTP id h6mr6366268pjs.103.1621532809382; Thu, 20 May 2021 10:46:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Thu, 20 May 2021 13:46:38 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary="00000000000018527d05c2c687b8"
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 17:46:56 -0000

On Thu, May 20, 2021 at 1:03 PM Viktor Dukhovni <>

> On Thu, May 20, 2021 at 04:45:23PM +0000, Andrei Popov wrote:
> > ALPN IDs are byte strings; the fact that some of them can be displayed
> > as ASCII character strings merely reflects the fact that those ALPN
> > IDs were chosen by humans😊.
> That's fine when they're just private signalling between a homebrew
> client and homebrew server, but for ALNP values registered with IANA,
> used in DNS HTTPS/SVCB records, ... the byte strings do need to be
> broadly usable, so that any site operator can add them into their DNS
> zone, type them into a web form, ...
> If ALPN values are BIDI strings, with mixed left-to-right and
> right-to-left fragments, comtain accented characters that may have
> different NFKC vs. NFKD forms... usability and interoperability suffer.

> It is fine for the TLS protocol to not care, but the *standard* ALPN
> values in the IANA registry (that might then also appear in DNS
> zone files, configuration files, ...) a more restricted character
> set would actually be helpful.

I'm a little torn here, because you've again mentioned usability and
interoperability suffer, but it's unclear if you're seeing that as a
generic statement or simply "with respect to configuring DNS zone files".

Saying BIDI, LTR/RTL or NFKC/NFKD are issues here is like saying TLS
wireprotocol version field itself suffers from left-to-right issues. Such a
statement makes no sense, because the version, like the ALPN, is a byte
string. We don't say that the TLS version is "COMBINING TILDE" (U+0303), we
say it's 0x03 0x03, or, if we want to make the string human readable, we
convert it to a value that has no relation to its wire representation -
such as "TLS 1.3"

The suggestion here, of restricting the registered set, seems like it
should equally be obvious as creating and amplifying interoperability
issues, rather than resolving them, because of the assumption again that
values will be ASCII, even though that's not what the wire protocol
assumes. APIs, from the TLS implementation itself to those that expose or
rely on the TLS information (such as the Web APIs previously mentioned)
would, if such a path as you suggest here were adopted, no doubt assume
that despite the spec saying it's a byte string, it's in fact an ASCII
string. Such APIs and design assumptions quickly permeate systems, and as a
consequence, interoperability is harmed.

This issue is, functionally, an example of that. It seems like the issue is
not at all related to the DNS wire format, which is perfectly happy with
this, but rather the configuration text syntax used with DNS, and not
wanting to do things like escape byte sequences. This is why it seems like
it's simply a matter of being inconvenient, but have I misunderstood and
there's a deeper issue I've missed?