Re: [TLS] NextProtoNeg concerns

[Yoav Nir <[e-mail]>]

On Nov 18, 2011, at 2:32 PM, Adam Langley wrote:

> On Fri, Nov 18, 2011 at 12:17 AM, Yoav Nir <[e-mail]> wrote:
>> If you are defining a new extension/handshake message to carry a new kind of data (application type) there is no value to this without a definition of the format, either in the same document or in a companion document.
> 
> I agree. The current, sparse form of the draft was simply intended to
> omit details in order that the more salient points be obvious.
> 
> I would absolutely expect that any draft would end up specifying the
> format of the messages; something like:
> 
> "Protocols are named by opaque, non-empty byte strings and the list of
> protocols is serialized as a concatenation of 8-bit, length prefixed
> byte strings. Implementations MUST ensure that the empty string is not
> included and no byte strings are truncated."
> 
> "The NextProtocol message has the following format:
> 
> struct {
>  opaque selected_protocol<0..255>;
>  opaque padding<0..255>;
> } NextProtocol;
> 
> The contents of selected_protocol are a protocol but need not have
> been advertised by the server. The length of padding should be 32 -
> ((len(selected_protocol) + 2) % 32). Note that len(selected_protocol)
> does not include its length prefix."

I would strongly prefer that it not say "opaque" but rather point to a registry of strings, similar to the TLS exporter label registry
http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#exporter-labels

That does not have to mean that you need to publish an RFC for each label. The label space is huge, even if we limit in to case-insensitive latin letters plus numbers, slash, point, dash and colon, and up to 12 characters, it still dwarfs the US national debt expressed in Taiwanese cents (assuming there is such a thing as a Taiwanese cent). So a registry like that could be set up on a fcfs basis, with some reserved prefixes (priv-, exp-, com-companyname-) that could be used without registration. Or maybe require a priv- or exp- prefix for anything not specified at all, FCFS or expert review for other prefixes, and standards action for things that don't have a prefix (like "http/1.1", or "SSTP" if Microsoft chooses to document it)

Yoav