On Thu, May 20, 2021 at 11:19 AM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> 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. > Encoding ALPN identifiers in hex for these configuration files sounds like a very straightforward way to support all valid ALPN identifiers. We already have "exotic" ALPN identifiers in the registry (for GREASE). Any new scheme that handles ALPN should be designed to handle all possible values. Not doing so will lead to interoperability issues that others have already mentioned. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
