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

Nick Harper <ietf@nharper.org> Thu, 20 May 2021 23:15 UTC

Return-Path: <nharper@nharper.org>
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 444A53A0EC1 for <tls@ietfa.amsl.com>; Thu, 20 May 2021 16:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 8_1PDY0JW6QR for <tls@ietfa.amsl.com>; Thu, 20 May 2021 16:15:40 -0700 (PDT)
Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBEB83A0EC0 for <tls@ietf.org>; Thu, 20 May 2021 16:15:39 -0700 (PDT)
Received: by mail-ua1-f51.google.com with SMTP id n61so6067558uan.2 for <tls@ietf.org>; Thu, 20 May 2021 16:15:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WHCGG7EB9RiamkMkjOma+oce7BF8uQuOXzpLM250/wI=; b=bmTb5heSMEo0wHUUybqFnFu+NOnK1JXE1GhB93KartVf/LcOs2HnYT2JtTHrycINKo ttu/rXmK7YV2sxdxVGeQCMV7Zvi360PllVBWNchC++J4Mk8c/Rmaaruv/g181SEfucwQ cDo7tTWjRA5dvx2PTqkh5/1yy+YajsNRDqRnFeUoddcoZHnW6YO1EjrHDuW4pI7c23Od PrI5NcAchni/LQHyhOkitDhxqtz/jH4kskyIolPJCpnwi+4vk5umXYDzisdJ/yXaRinu HcqZSAStEPzcLB4lONPysHDBEKrkzStBdNy/BckODPhw9GqE6BfB8I/l7VGFJsGoHAdZ onKg==
X-Gm-Message-State: AOAM533CsfXZ6/UyMonN2AdQs15zHQuXvWeaHI5PvBUj5RNl9JQ5lblb PrIxaJqbCFKpEJ0KsgWG+ha5SoZI4TYKZ6EhDsUGCS1gg7nxt1imCLk=
X-Google-Smtp-Source: ABdhPJytISiv+Gz7SqSIgtrdrCiobjx8L+DKYY+/KoY7dMRcXR7N020ur9Ij9flkH7CYnFw9F13wSP5cHLptz7KnGDM=
X-Received: by 2002:ab0:36b4:: with SMTP id v20mr6980459uat.67.1621552538035; Thu, 20 May 2021 16:15:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAKC-DJjSq2sVKsJphX4QQBHOBojnTVHNE-wkdnZyZtv8NiGpQA@mail.gmail.com> <B3472BAC-AB21-4E5F-B18D-DC7179E4EA8F@akamai.com> <YKX5vXDSHrvVzHy6@straasha.imrryr.org> <CAErg=HH5DfBpkPx48NKy4air1N1FKiwVCttYz5ddCfw+K3eQuA@mail.gmail.com> <DM6PR00MB0713CB495B3FFEFCA0DD95338C2A9@DM6PR00MB0713.namprd00.prod.outlook.com> <YKaWNfguJPyL1QSZ@straasha.imrryr.org> <CAErg=HFjOi5=u8pDA713MBDw2YLZczy0EYDzGN6DRH8OGPPOEw@mail.gmail.com> <YKaoKnrziIBON2Y5@straasha.imrryr.org> <CACcvr=k=8-myYtCPshWoJPiz2gQE6_202_7vnxertAx624MnmA@mail.gmail.com> <YKbo/ODtsZOmGmcQ@straasha.imrryr.org>
In-Reply-To: <YKbo/ODtsZOmGmcQ@straasha.imrryr.org>
From: Nick Harper <ietf@nharper.org>
Date: Thu, 20 May 2021 16:15:27 -0700
Message-ID: <CACcvr==kNEB0M8xqMKno6C0SrB02ju3KC7S7UznLujsHF1fZRA@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="00000000000003bc2505c2cb1fed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/R5qX4PnJKlOywUPnTf5Hxsw4ASw>
Subject: Re: [TLS] [EXTERNAL] Re: 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 23:15:44 -0000

On Thu, May 20, 2021 at 3:56 PM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

> I agree it is a straight-forwarding encoding for machines, and it is
> well suited for the GREASE code points.
>
> But, it makes for a fairly terrible user interface for the human
> operator.  Compare:
>
>     * managesieve
>     * 6d616e6167657369657665
>
> Typos in hex values are easy to make and hard to recognise.
>
> I agree that it's not a great user interface for the human. A good
solution to that is to let the user define a constant with the hex value
(or build the ALPN constant into the config language), like how with
OpenSSL one can specify "ECDHE-ECDSA-AES128-GCM-SHA256" instead of 0xC02B.
Using your example, one could define a constant ManageSieve = {0x6d 0x61
0x6e 0x61 0x67 0x65 0x73 0x69 0x65 0x76 0x65} and reference that constant,
and if a typo were made (e.g. one put ManageSeive in the config), the
config would fail fast, vs if one configured "manageseive" as the ALPN
directly, the typo would propagate further through a deployment before
being detected/fixed.

There are good solutions to solve the human factors of managing/configuring
ALPN that don't require imposing restrictions on what ALPN can go on the
wire in TLS. Those solutions should be favored over restricting the wire
protocol/code point allocation.