On Thu, May 20, 2021 at 03:06:06AM -0400, Ryan Sleevi wrote:
> On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni <ietf-d...@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?
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=
> 40akamai....@dmarc.ietf.org> 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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
