On Thu, May 20, 2021 at 1:03 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Thu, May 20, 2021 at 04:45:23PM +0000, Andrei Popov wrote: > > > ALPN IDs are byte strings; the fact that some of them can be displayed > > as ASCII character strings merely reflects the fact that those ALPN > > IDs were chosen by humans😊. > > That's fine when they're just private signalling between a homebrew > client and homebrew server, but for ALNP values registered with IANA, > used in DNS HTTPS/SVCB records, ... the byte strings do need to be > broadly usable, so that any site operator can add them into their DNS > zone, type them into a web form, ... > > If ALPN values are BIDI strings, with mixed left-to-right and > right-to-left fragments, comtain accented characters that may have > different NFKC vs. NFKD forms... usability and interoperability suffer. > 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". 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. 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" 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. 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. Such APIs and design assumptions quickly permeate systems, and as a consequence, interoperability is harmed. 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. 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?
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
