Re: [TLS] Revision of draft-friedl-tls-applayerprotoneg posted

[Yoav Nir <[e-mail]>]

Hi

I support the adoption of this draft. I think it solves the problem of multiplexing multiple protocols on a single TLS-protected port.  I prefer it to NPN for the following reasons:

  1.  It is a simpler solution - just another extension and a simple selection mechanism on the server. Implementing this would require less LoC in pretty much any implementation.
  2.  I do not believe that the choice of HTTP/1, HTTP/2 or various versions of SPDY (which should be experimental anyway) needs to be secret. The value space is small enough that whatever advantage an attacker might get by having the protocol revealed, can be gotten by trial and error as well.
  3.  More similar to existing TLS, so less surprises by proxies and middleware, so less need to fall back.
  4.  More friendly to middleware - TLS proxies that will anyway drop HTTP/2 can do so earlier. I realize some will not consider this an advantage…

Reading through it, I have a few suggestions:

I think there should be a special alert message to note that none of the applications are supported. Call it no_application_chosen, rather than use handshake_failure.

I think the SPDY variants should be prefixed by exp and not registered by IANA

Also, I think there should be a prefix for private protocols, not marked as experimental. For example, we could have it say P-author_identifier-name. So if Microsoft wanted to negotiate the sue of SSTP, they could mark it as P-MSFT-SSTP

Yoav


On Feb 6, 2013, at 5:09 AM, Stephan Friedl (sfriedl) <[e-mail]<mailto:[e-mail]>> wrote:

Hello All,

A revised version of ‘Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension’ (draft-friedl-tls-applayerprotoneg-01) has been posted.  This version includes a number of significant improvements to the original draft including:

1.            Use of a single extension for both the ClientHello and ServerHello messages
2.            Definition of ProtocolIdentifiers as opaque, non-empty byte strings and the list of protocols is serialized as a concatenation of 8-bit, length prefixed byte strings
3.            Clarification of the suggested order of client-side ProtocolIdentifiers
4.            Clarification that the server-side extension_data MUST contain exactly one ProtocolIdentifier
5.            Should the server support none of the protocols advertised by the client, then the server SHALL respond with a ‘fatal handshake failure alert’.
6.            Addition of Andrei Popov of Microsoft as a co-author

These changes were largely proposed by Andrei and have greatly improved the draft.

I would greatly appreciate any comments and feedback on the draft.

Thanks and Best Wishes,

Stephan