[TLS] NextProtoNeg concerns

[Yoav Nir <[e-mail]>]

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