Re: [TLS] Narrowing allowed characters in ALPN ?

Mark Nottingham <mnot@mnot.net> Thu, 20 May 2021 07:50 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C753A1094 for <tls@ietfa.amsl.com>; Thu, 20 May 2021 00:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=AbqDXOxW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DNrIyvRd
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9TtEhM6e1QC for <tls@ietfa.amsl.com>; Thu, 20 May 2021 00:50:04 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADB03A108F for <tls@ietf.org>; Thu, 20 May 2021 00:50:04 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3BF515C0101; Thu, 20 May 2021 03:50:03 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 20 May 2021 03:50:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=1 IC90Pv4E56kuIlpgKCcXk1IqC4ztu9mgwynn6tkQ1o=; b=AbqDXOxW6S/fDuJve e3RjvBFX/0LoctlVQS9eqc2uryWMcw9rW6vbLDS+9+jHtxN7ayxYNDwk1kH4ivg5 rTHZRQdQ2UTj0Ng4GG/PcUA2SVykQs1Fw4c/yK8QLdAaQDpsYj2K/D4cOL6nMTD/ wAseEK+/+DfhYLXJksKpgh2rff6yNmFe1x1jdi065wDCJeNUzWmq6u2mY2dcC23f oC7hykL3vXvheCStv3katTK85Og0q79DG+jfGVfq5vP9IuFXD9527bl1N90GstXe gHkEZ9+QIbWFyUJzPxcgvQvUZnsekV47i0tUOCKLPU0f1+iA/DGasZY6ChSH+EX6 /05mg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=1IC90Pv4E56kuIlpgKCcXk1IqC4ztu9mgwynn6tkQ 1o=; b=DNrIyvRdEjjR5pzdHwyW17wvQNR566OU41zimIKPNmnlTHKkVATCA02el vlb3Pbgagt1BxfIyqvu8hlMbzpYIPv1/95eIXKr9J3x/7BkUQC/2rlPkp8hyid4D 1i8P7ebx1C/hutU7Gs6wXmmtP2/itlx6phDOw15NuOeRJ2SRdSQtLJAYLHGkvyFG iqSeMXJ3Pq86UwcVNQeuEXBP17Gma6NCQWq/HK+/DQ3X7GvtxthI+cVWCjITF3P5 iak4237JA6AE7fjwl7UZR6w44XIub3t4i9ubGAaGYHgW+DJ28gYHeMjAFj9smLko R///09r7yO3UvC6SUbOtoNmJPL8MA==
X-ME-Sender: <xms:qRSmYIFQBvrtT0y6HA_v8CLNO0HsBKl9nPQxTbFBQ4X6Xz-pbfjMUQ> <xme:qRSmYBVJ5n2AmfXikodlUxnxNrhSazc2XrVbnsLIYX3ivnuIug2ccJ6bAh6qAfwG6 PuxZhPOyCwma2kZkA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejtddguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesth hqmhdthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothes mhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekuddvleejgeethfevkefhtdevke elveekfeegleduiefhudegvdeiuefftddthfenucffohhmrghinhepihgvthhfrdhorhhg pdhmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdr nhgvth
X-ME-Proxy: <xmx:qRSmYCJUcg1Ge_Xnvm6FLarfr84K7hv6gnKCQ3T0XxVCqjEUhp1ePg> <xmx:qRSmYKHKf8GMeNKGRYJBmgCysGfM6gSntNj2hDsgauesttxs61zrfg> <xmx:qRSmYOWwJdq9tHgTZGRceHDCHGKnqOpd7sYhCqImsNUn_X9QLlbhdw> <xmx:qxSmYLgVnhCewcXZR8GhJjkAwI2mo68R2NeeBCtgZS6OMuqUF56ndQ>
Received: from smtpclient.apple (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 May 2021 03:50:00 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAErg=HH5DfBpkPx48NKy4air1N1FKiwVCttYz5ddCfw+K3eQuA@mail.gmail.com>
Date: Thu, 20 May 2021 17:49:56 +1000
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F92AEE1D-17AB-4DD0-A585-E0041D38F028@mnot.net>
References: <CAKC-DJjSq2sVKsJphX4QQBHOBojnTVHNE-wkdnZyZtv8NiGpQA@mail.gmail.com> <B3472BAC-AB21-4E5F-B18D-DC7179E4EA8F@akamai.com> <YKX5vXDSHrvVzHy6@straasha.imrryr.org> <CAErg=HH5DfBpkPx48NKy4air1N1FKiwVCttYz5ddCfw+K3eQuA@mail.gmail.com>
To: Ryan Sleevi <ryan-ietftls@sleevi.com>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/081GQ7jUjI6jAXNRmBenEMTx_RY>
Subject: Re: [TLS] Narrowing allowed characters in ALPN ?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 May 2021 07:50:09 -0000

For better or worse, these identifiers are being used in places outside the TLS handshake -- for example, in HTTP header fields, as Erik mentioned. That brings the encoding / conversion concerns he mentioned. It would be simpler (and likely safer) to only allow ASCII strings in those uses (at least).

Cheers,


> On 20 May 2021, at 5:06 pm, Ryan Sleevi <ryan-ietftls@sleevi.com> wrote:
> 
> 
> 
> On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> 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. 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--
Mark Nottingham   https://www.mnot.net/