Re: [TLS] Narrowing allowed characters in ALPN ?

[Viktor Dukhovni <[e-mail]>]

On Thu, May 20, 2021 at 03:06:06AM -0400, Ryan Sleevi wrote:

> On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni <[e-mail]> 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?

See below.  The idea is not to ask TLS implementations to reject
non-ASCII ALPN values, but rather for non-ASCII values to not be
defined, facilitating better interoperability among systems that
exchange ALPN values outside of TLS in various serialisation contexts.

> 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.

Yes, in TLS, but once they end up in DNS zones, configuration files,
pasted into web forms (to update DNS HTTPS/SVCB records...) various
pain points arise.

On Thu, May 20, 2021 at 07:39:59AM -0700, Ben Schwartz wrote:
> On Thu, May 20, 2021 at 6:30 AM Salz, Rich <rsalz=
> [e-mail]> wrote:
> 
> > Look at RFC 701, it says: the precise set of octet values that identifies
> > the protocol. This could be the UTF-8 encoding of the protocol name.
> >
> > So I changed my mind and think it's okay to leave as-is but wouldn't mind
> > if it became less general or more specific. For example, what if a protocol
> > string matches a truncated UTF8 string?  It makes me think of SNI which
> > could have any format, but really is "any format as long as it's a DNS name"
> 
> One intermediate option might be to keep the ALPN TLS extension 8-bit
> clean, but change the IANA instructions for the ALPN registry to tighten
> the registration requirements.

Yes, this, but also a commmitment to keep it that way, so that e.g.
HTTPS/SVCB can rely on not needing to encoding ALPN values that are
non-ASCII, have control characters, commas, double-quotes, ...

So the below should suffice:

    * lower-case ASCII letters a-z
    * ASCII digits 0-9
    * "+", "-", ".", "/" and "_"

-- 
    Viktor.