Re: [TLS] NextProtoNeg concerns

[Adam Langley <[e-mail]>]

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


Cheers

AGL