IETF Logo Mail Archive

Re: [TLS] Narrowing allowed characters in ALPN ?

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 20 May 2021 05:55 UTC

Return-Path: <ietf-dane@dukhovni.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 8D41A3A0813 for <tls@ietfa.amsl.com>; Wed, 19 May 2021 22:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 H-VyboZlwF4x for <tls@ietfa.amsl.com>; Wed, 19 May 2021 22:55:12 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8313A3A0809 for <tls@ietf.org>; Wed, 19 May 2021 22:55:10 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 47FE3D42BF; Thu, 20 May 2021 01:55:09 -0400 (EDT)
Date: Thu, 20 May 2021 01:55:09 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <YKX5vXDSHrvVzHy6@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <CAKC-DJjSq2sVKsJphX4QQBHOBojnTVHNE-wkdnZyZtv8NiGpQA@mail.gmail.com> <B3472BAC-AB21-4E5F-B18D-DC7179E4EA8F@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <B3472BAC-AB21-4E5F-B18D-DC7179E4EA8F@akamai.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/c22bTLEv-Ddz6dT7EFGOsYnkg3U>
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 05:55:15 -0000

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.

We don't want to embed ASCII NUL bytes in these, worry about potential
corruption when they get embedded in text strings and undergo transforms
from ISO-Latin to UTF-8 or back, ...

The more vanilla the character set the better.  The HTTPS record
constructs comma-separated lists of these in quotes, so it has to
deal with escaping quotes and commas, and other needless pain.

We're not helping anyone by insisting that the original definition was
wise.  It can and should be revised.

-- 
    Viktor.

v2.23.0 | Report a Bug | By Email