Subject: [TLS] NextProtoNeg concerns

From: Yoav Nir <[email-masked]>
Date: Fri, 18 Nov 2011 07:17:56 +0200

Hi

I'm all for the working group accepting this item. I agree with EKR that traffic analysis will probably be able to distinguish all protocols, so I don't think it matters very much one way or the other whether the NextProtocol handshake is encrypted or not. I don't even thing that the NextProto handshake message is even necessary, as both sides have agreed on the capability, and can send the selected_protocol as the first few bytes of the application data, but again, I don't think this makes much of a difference one way or another.

What I really don't like about this proposal, is this text in section 3:
   The "extension_data" field in a "ServerHello" and the "NextProtocol"
   message contain opaque bytes to be used by the application layer to
   negotiate the application layer protocol.  The format of this data is
   not specified in this draft.

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.

The examples in the slides show a very specific format: "\x06spdy/2\x08http/1.1\x08http/1.0". I don't see why this would not be specified in the document. Of course, you would need to set up a registry for these strings. For example, I can see how Microsoft would want to register SSTP, and other vendors would register their own SSL-VPN protocols as well.

With that section added, I support adoption of this document.

Yoav

---

From: Marsh Ray <[email-masked]>
Date: Thu, 17 Nov 2011 23:36:08 -0600

On 11/17/2011 11:17 PM, Yoav Nir wrote:
>
> What I really don't like about this proposal, is this text in section
> 3: The "extension_data" field in a "ServerHello" and the
> "NextProtocol" message contain opaque bytes to be used by the
> application layer to negotiate the application layer protocol.  The
> format of this data is not specified in this draft.
>
> 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.
>
> The examples in the slides show a very specific format:
> "\x06spdy/2\x08http/1.1\x08http/1.0". I don't see why this would not
> be specified in the document. Of course, you would need to set up a
> registry for these strings. For example, I can see how Microsoft
> would want to register SSTP, and other vendors would register their
> own SSL-VPN protocols as well.

What if you're a small application developer, perhaps with a single 
application or running only a few servers. Should you be expected to 
register your format before using it?

Would it be expected to follow the same length-value format as the example?

Would anyone ever be denied registration? What if their format 
definition was technically deficient, or they wanted to reserve a bunch 
of unrelated protocol names?

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Fri, 18 Nov 2011 13:38:20 +0200

> of unrelated protocol names?

That would be up to the draft to specify. You could do it as FCFS or technical expert review - no need for a draft.

And we could reserve some prefixes, like exp- (for experiment) and priv- (for private protocol). You could then safely use "exp-marshray-test1"

---

From: Adam Langley <[email-masked]>
Date: Fri, 18 Nov 2011 08:32:05 -0500

> 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…

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

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Nov 2011 12:15:17 +0200

> 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

---

From: Adam Langley <[email-masked]>
Date: Mon, 21 Nov 2011 17:54:37 -0500

> 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,…

I would be happy with a low-friction registry of names.

Cheers

AGL