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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 20 May 2021 18:19 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 7E4EF3A214C for <tls@ietfa.amsl.com>; Thu, 20 May 2021 11:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 ZbdeaNKQkDsF for <tls@ietfa.amsl.com>; Thu, 20 May 2021 11:19:24 -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 AF57D3A2144 for <tls@ietf.org>; Thu, 20 May 2021 11:19:24 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 7D310D4B37; Thu, 20 May 2021 14:19:22 -0400 (EDT)
Date: Thu, 20 May 2021 14:19:22 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <YKaoKnrziIBON2Y5@straasha.imrryr.org>
Reply-To: tls@ietf.org
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAErg=HFjOi5=u8pDA713MBDw2YLZczy0EYDzGN6DRH8OGPPOEw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vHHwsgmjo0ArhQsCSy0XzAxSskU>
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 18:19:29 -0000

On Thu, May 20, 2021 at 01:46:38PM -0400, Ryan Sleevi wrote:

> > It is fine for the TLS protocol to not care, but the *standard* ALPN
> > values in the IANA registry (that might then also appear in DNS
> > zone files, configuration files, ...) a more restricted character
> > set would actually be helpful.
> 
> I'm a little torn here, because you've again mentioned usability and
> interoperability suffer, but it's unclear if you're seeing that as a
> generic statement or simply "with respect to configuring DNS zone files".

At present, more the latter, but not exclusively so, since there are
likely other places where operators might be recording choices of
supported ALPN values in configuration files.

> Saying BIDI, LTR/RTL or NFKC/NFKD are issues here is like saying TLS
> wireprotocol version field itself suffers from left-to-right issues. Such a
> statement makes no sense, because the version, like the ALPN, is a byte
> string.

And indeed at present also in the DNS wire format.  What's new, is that
those values are now also going to be manipulated by operators in their
presentation form, which gets rather unwieldy when the values happen to
contain commas, double-quotes, control characters, ... let alone strings
that in UTF-8 appear to be NFKD, BIDI, ...

> We don't say that the TLS version is "COMBINING TILDE" (U+0303), we
> say it's 0x03 0x03, or, if we want to make the string human readable, we
> convert it to a value that has no relation to its wire representation -
> such as "TLS 1.3"

Of course, we all understand they're plain octet-strings.  But that does
not help the poor operator trying to enter them into a config file or
a web form.

> The suggestion here, of restricting the registered set, seems like it
> should equally be obvious as creating and amplifying interoperability
> issues, rather than resolving them, because of the assumption again that
> values will be ASCII, even though that's not what the wire protocol
> assumes.

I don't see a substantial risk that TLS stacks will start to not treat
the ALPN string as an opaque byte string, it would take more code to do
otherwise.

> APIs, from the TLS implementation itself to those that expose or
> rely on the TLS information (such as the Web APIs previously mentioned)
> would, if such a path as you suggest here were adopted, no doubt assume
> that despite the spec saying it's a byte string, it's in fact an ASCII
> string.

This is of course possible, but does not look like a substantial risk.
And there's always GREASE.

> This issue is, functionally, an example of that. It seems like the issue is
> not at all related to the DNS wire format, which is perfectly happy with
> this, but rather the configuration text syntax used with DNS, and not
> wanting to do things like escape byte sequences.

Correct, but more than just DNS, basically any data-at-rest
serialisation of ALPN values in configuration files, or use
with interactive data entry, ...

> This is why it seems like it's simply a matter of being inconvenient,
> but have I misunderstood and there's a deeper issue I've missed?

The incovenience means that applications that process SVCB/HTTPS data
entered by users need much more complex and easier to mess up parsers.

Since the likelihood of actually adding exotic ALPN values to the
registry appears slim, why not say so.  That would leave the exotic
values for private on-the-wire use, while allowing DNS and other
configuration serialisation forms to avail themselves of more
straight-forward parsers.

-- 
    Viktor.