Re: [TLS] Narrowing allowed characters in ALPN ?

Martin Thomson <> Thu, 20 May 2021 00:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D74733A2603 for <>; Wed, 19 May 2021 17:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=2/J+FFtg; dkim=pass (2048-bit key) header.b=JxxbYc9G
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fKCshJrrFdQr for <>; Wed, 19 May 2021 17:47:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D8443A2601 for <>; Wed, 19 May 2021 17:47:49 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id AC12E31E for <>; Wed, 19 May 2021 20:47:46 -0400 (EDT)
Received: from imap10 ([]) by compute2.internal (MEProxy); Wed, 19 May 2021 20:47:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=X2J+zVXyknT1RlAmSCA7wTPlIIiJxwS O5keyYUZ9umo=; b=2/J+FFtgPkW4I8MWYiUDvb7V9w+4PZZxqxTo2g3Ej7j+uOE F6/gyrf8c7R5BD6FnoC479ndJH+z64j3XylozU8m7bCtg9XLouMl4DAt8kongJNm uw9ClQ9c+N5lfD+E157Dzaf92vyG/ufLNwCVKPiAe+0cNDxBOBT73EGylxld7v6f ojp7sQvdsRQVmwLnt5z7qVuxJBubLEu4xMOIjqgvfuJA5PwFLA0TEJoWTa5Tt7+O tVVbxWIEY90EirP3nfzRpfKo+0rwA5GRJ7fTmjgS2PlfD6FQJIydVOozQsWnsJ4w zPHIiTZ0+o/De+641F6qapRkGNE5oxeZBHtk0TQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=X2J+zV XyknT1RlAmSCA7wTPlIIiJxwSO5keyYUZ9umo=; b=JxxbYc9G0xarrEUAsUV6LF 8RaP7TKdwGkNyBVlGTvInuU+DYTk52/vbhZEbe7y9X5K3g3VqGWV1hNyuV7J9l8o Ux/Qz8LMo2Zh/302jKmudKQVAkC23EOcKG3++IQXakAxULwhZ+J55xCkw8q2seU0 J/7InTH55NRSVtaqnazPwzkkjOo1nkDLWIu8RYDXjP8++JcLArYglkMgyAo0VvW3 PltuUdlN07NbCEfmWwfzokftccQOJzpqX5XNZO6PyEZu2JU8a9Xfha9zXj8ettEq VOrTksN1FYamKg40s6JWPisEWrXZjaFIyqrGGkuoLAd6JiaoPkVAyKL6z7UBtrvw ==
X-ME-Sender: <xms:sbGlYGyb0FBA7pG4llvgFb0ysOGoqYdTR48wFnuZApxIeo_HldDi_w> <xme:sbGlYCRR-ws8aAw-3hJoj8Ex-89Y1lrExBrL5BOdqiB_G2FrJXqXK2J7CPzxwY8ab AgsNLHvSwUi6vOzaEE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejtddgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefgueegfeettdejgeehgf ejhfffieeihffhveejtdffjeeuveejudfhhfetvddvheenucffohhmrghinhepgedtihgv thhfrdhorhhgpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:sbGlYIU8eOFQoYmLRefOOcJuCRWAbvDPb5I_RnGnQJHHaBGmIc03pA> <xmx:sbGlYMiuEGwVpYT01UcJdDPXVv8zmwNJgKopzwMQ_09uz9PE2E0fcA> <xmx:sbGlYIDfxcwath_BnDkLVJwkwHQvkg9wEViS8q0DqNOwhVP8NyM3Pg> <xmx:srGlYLOHWBKr6wCQj7ib8RwlNlbmweWEw3Aq5XWNOf8tjUUuep1dZQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id DCBAD4E00BE; Wed, 19 May 2021 20:47:45 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Thu, 20 May 2021 10:47:25 +1000
From: "Martin Thomson" <>
Content-Type: text/plain
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 00:47:55 -0000

I think that we would need stronger reasons than "it's annoying".  There are good reasons to use octets that map to simple ASCII.  We should continue to only define identifiers that use those characters.  However, a specification is also a commitment and whether or not it was a good idea, we (this working group and the IETF as a whole) made that commitment.

I tend to think that as long as it isn't broken, it doesn't need fixing.  And we have - on various occasions - discussed using the capability.

Were we to define this all over, I'd be supportive of restrictions, but it's not worth fixing now.

On Thu, May 20, 2021, at 07:29, Erik Nygren wrote:
> With draft-ietf-dnsop-svcb-https being in WGLC in DNSOP, one feedback 
> that
> has come up is that the escaping and parsing for SvcParamValues is 
> complicated.
> Most of this complication comes from trying to support 8-bit clean ALPN 
> values.
> Ideally in presentation format the ALPN list would be something like 
> "h2,h3,http/1.1"
> but at the same time the current definition of ALPN as being a series 
> of binary
> octets means that we need parsing and escaping rules.
> When httpbis defined Alt-Svc, quite a bit of complexity showed up there
> as well for supporting an 8-bit-clean ALPN value while allowing for an 
> ascii
> representation for most codepoints.  It seems likely that other 
> specifications
> may run into the same challenge.
> Would there be support for updating the ALPN registry to 
> indicate that registered ALPN values need to conform to a subset of token
> characters?   There is a separate question for the process of making
> this change, but before even exploring that it seems necessary to ask
> the TLS WG if there are strong opinions on this one way or the other.
> From a usability perspective, non-token ALPN values will have challenges
> in many of the systems that may try and configure them, as well
> as for rendering special characters in various systems that may handle ALPNs.
> The codepoint space is also massive so it isn't clear that there's a compelling
> need to support 8-bit ALPN from a code point conservation perspective.
>    Erik
> _______________________________________________
> TLS mailing list
> <>