Re: [TLS] Narrowing allowed characters in ALPN ?

Ryan Sleevi <> Thu, 20 May 2021 07:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F2B23A0E1A for <>; Thu, 20 May 2021 00:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Status: No, score=-1.401 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_NONE=-0.0001, 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 WojtK4VOkHjS for <>; Thu, 20 May 2021 00:06:18 -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 595493A0DBD for <>; Thu, 20 May 2021 00:06:18 -0700 (PDT)
Received: by with SMTP id v12so8462523plo.10 for <>; Thu, 20 May 2021 00:06:18 -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=QviUDu7t7I4LD3cc1kG4DymfoNDL1NnHgow2u1/i89M=; b=rX715o+pu4hBq+AVTBo0D6v0NVVOoaEf2gTnAqHTeuM42azrp5uekm0dNEEXyl2Nri ISmfGgVeNJOexC0Q8hzYF9PX4VvfApNKQt/XywIndTee05yR4ygqGPWyN7otOndayh+5 xeK9WGboRTbJWY/L47P9uKh4II5auIFlF+9Eu/HZCr/RwdEmsZiRmRQFd230WdQaMlRO +SekmMmL53dyTB1tUR8sWiiLNwxDBU6z00Pzlt1QFiuRawr4BLOujCwtW3aXTNPxOHQG gv594SAwF+rHWT7jVHe2bhfMqm/8J3Zkh8L1b1neMVeSEl+ECfWD6GCEQTel88KIMSfy PVuA==
X-Gm-Message-State: AOAM530nB0EIGDci/nx4exkCGPimA5byEhNHH2hW4o+bEuLMEiSZjSSy AUZ7bcsA+nelEtvZ1zr7FoDIENo6GyU=
X-Google-Smtp-Source: ABdhPJyNWjdogQ27XOkxKn3Z9FxEp+fia+aYz35/ki3GhebhN5RPE+BldgKXVNfzNaDXtspuBeTnaw==
X-Received: by 2002:a17:90a:6f06:: with SMTP id d6mr3322036pjk.216.1621494377508; Thu, 20 May 2021 00:06:17 -0700 (PDT)
Received: from ( []) by with ESMTPSA id 11sm1138765pfh.182.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 May 2021 00:06:17 -0700 (PDT)
Received: by with SMTP id t21so8490119plo.2 for <>; Thu, 20 May 2021 00:06:17 -0700 (PDT)
X-Received: by 2002:a17:90a:2ec6:: with SMTP id h6mr3663255pjs.103.1621494376832; Thu, 20 May 2021 00:06:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Thu, 20 May 2021 03:06:06 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary="00000000000056226d05c2bd948a"
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 07:06:32 -0000

On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni <>

> On Wed, May 19, 2021 at 10:29:43PM +0000, Salz, Rich wrote:
> > I support limiting it.
> I concur.  These are not strings used between users to communicate in
> their native language.  They are machine-to-machine protocol
> identifiers, and use of the narrowest reasonable character set promotes
> interoperability.

I'm not sure I understand this. Could you expand further how adding more
normative restrictions promotes, rather than harms, interoperability?

The fact that, as you highlight, they are machine-to-machine, seems like
the greatest path to interoperability, because they shouldn't be assumed to
be "human-readable", and because as specified, no other validation needs to
be performed by either party. They should simply be treated as they're
specified: an opaque series of bytes. Conversions to text strings or
transformations such as character sets seems like fundamentally
misunderstanding/misusing them, rather than being a thing to support.

The idea of restricting the character set seems like it only opens the door
for less interoperability and more complexity. For example, senders need to
make sure they're sending within the allowed character set (meaning
validation before transmission), and receivers that wish to avoid malicious
peers need to similarly validate the identifiers before exposing them as to
API callers. This then adds complexity to the API design, as "no fail"
operations now become "maybe fail" (e.g if a caller attempts to call with
an invalid character string), and that propagates throughout the design of
systems (e.g. config files that may fail to load now).

It seems there's a parallel here to the discussion about whether HTTP/2
should have been a text protocol, like HTTP/1.1 and its predecessors, which
had similar arguments to what's being raised now, versus the binary
protocol that was ultimately adopted.

If the argument is that the extensibility has already rusted shut because
the ecosystem ignored the spec and we didn't GREASE it by using ALPN
identifiers that actually behaved as opaque bytes, then we should at least
make an effort to document why and when that happened, so that mistakes
like that can be avoided in the future.