Re: [TLS] Some comments about draft-ietf-tls-applayerprotoneg-01

[Andrei Popov <[e-mail]>]

Hi Yoav,

Thanks for reviewing the draft.

Regarding the preference order of the protocol IDs, the language was intended to indicate that most of the time it makes sense for the server to choose according to the server's preferences; however an implementation may have valid reasons to ignore this and go with the client's order of preference (that's why SHOULD is used). We can change the wording, if this is not clear.

As for returning the protocol selection response, the idea is that an extension is optional, and can be ignored (e.g. when disabled, or for some implementation-specific reasons). I would rather retain this flexibility and keep MAY.

The current draft makes a distinction between IANA-registered protocol IDs and those not registered by IANA. The latter can be used privately, for experimentation, etc. We can devise a more elaborate namespace scheme if there is consensus in the WG that this would be desirable. Personally, I would rather keep it simple.

"hide" protocol ID seems to defeat the very purpose of hiding:). Those who are interested in hiding the negotiated protocol, usually don't want the intermediaries to be able to treat different protocols differently. E.g. proxies could easily filter out traffic which includes "hide" protocol ID.

Does it make sense to include a protocol list in the renegotiation handshake? I believe it is possible that one would want to renegotiate to a different application protocol.

Thanks,

Andrei

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Yoav Nir
Sent: Tuesday, June 25, 2013 12:33 AM
To: [e-mail] list
Subject: [TLS] Some comments about draft-ietf-tls-applayerprotoneg-01

Hi

I have read the draft, and think it is in good shape. There are some quibbles, however.

Section 3.1 says: 
  "ProtocolNameList" contains the list of protocols advertised by the
  client, in descending order of preference.
But section 3.2 says: 
  It is expected that a server will have a list of protocols that it
  supports, in preference order, and will only select a protocol if the
  client supports it.  In that case, the server SHOULD select the most
  highly preferred protocol it supports which is also advertised by the
  client.

It's not clear to me why the order of preference of the client makes any difference if the server chooses a protocol based on its own order of preference. I would remove that last sentence, and leave it up to the implementation whether it enforces its own order of preference (select the most preferred protocol that appears anywhere on the client's list) or the clients' (select the first protocol advertised by the client that you also support).


Section 3.1 has this rather confusing paragraph:
  Servers that receive a client hello containing the
  "application_layer_protocol_negotiation" extension, MAY return a
  suitable protocol selection response to the client.  The server will
  ignore any protocol name that it does not recognize.  A new
  ServerHello extension type
  ("application_layer_protocol_negotiation(16)") MAY be returned to the
  client within the extended ServerHello message.  The "extension_data"
  field of the ("application_layer_protocol_negotiation(16)") extension
  SHALL be structured the same as described above for the client
  "extension_data", except that the "ProtocolNameList" MUST contain
  exactly one "ProtocolName".

First, ClientHello and ServerHello extensions are pretty much the same (yes, I know the formatting sometimes changes), so there's no need to talk about "a new ServerHello extension type". Also, I can't figure out the MAY here. Not returning a response says that the server does not support this extension. A server compliant with this specification MUST send a response (or else a no_application_protocol alert). How about rewriting this as follows:

  Compliant servers that receive a client hello containing the
  "application_layer_protocol_negotiation" extension, MUST return a
  suitable protocol selection response to the client.  The server MUST
  ignore any protocol name that it does not recognize.  A 
  ("application_layer_protocol_negotiation(16)") extension MUST be 
  returned to the client within the ServerHello message.  The 
  "extension_data" field of the extension is structured the same as 
  described above for the client "extension_data", except that the 
  "ProtocolNameList" MUST contain exactly one "ProtocolName".



Section 3.1 also has this:
  Experimental protocol names, which are not registered by IANA, will
  start with the following sequence of bytes: 0x65, 0x78, 0x70 ("exp").
And this is repeated in section 4:
  A namespace will be assigned for experimental protocols, comprising
  byte strings which start with the following sequence of bytes: 0x65,
  0x78, 0x70 ("exp").  Assignments in this namespace do not need IANA
  registration.

I suggest a somewhat different namespace allocation:
 * Names that begin with "X-" (0x58,0x2D) are experiments, like "X-spdy/4"
 * Names that begin with "P-" (0x50,0x2D) are private, and shall have an organizational identifier, plus a protocol, like "P-MSFT-SSTP" or "P-CHKP-SNX"
 * Names that begin with "D-" (0x44,0x2D) denote drafts, and the rest of the byte string has the draft title minus the "draft" qualifier, for example "D-ietf-httpbis-http2-03". Since a slash (0x2F) is never part of the document name, a document that defines >1 protocols may add a slash and an internally-meaningful string, such as "D-ietf-httpbis-http2-03/no-header-compression"
 * IANA shall not assign any byte strings where the second byte is 0x2D. Such byte strings are reserved.



Section 4 says:
  Finally, by managing protocol selection in the clear as part of the
  handshake, ALPN avoids introducing false confidence with respect to
  the the ability to hide the negotiated protocol in advance of
  establishing the connection.  If hiding the protocol is required,
  then renegotiation after connection establishment, which would
  provide true TLS security guarantees, would be a preferred
  methodology.

How about making this more explicit. Add a special protocol called "hide", and have the client propose just that. They could even be using an anon-dh ciphersuite for that handshake. If "hide" is selected, no application data is tolerated within it, and the client MUST immediately renegotiate with a proper list of protocols. 

If both of my previous suggestions are accepted, I would change the initial registry to contain just "http/1.1" and "hide" for starters, as the spdy experiment can be accommodated by "X-" prefix, and the draft versions of HTTP/2.0 can be accommodated by "D-" prefix.



Finally, the end of section 3.1 says this:
  Unlike many other TLS extensions, this extension does not establish
  properties of the session, only of the connection.  When session
  resumption or session tickets [RFC5077] are used, the previous
  contents of this extension are irrelevant and only the values in the
  new handshake messages are considered.

This does not mention renegotiation. Suppose we are already running application data, and the client initiates a renegotiation. Makes no difference if this is of its own accord or because of a HelloRequest sent by the server. Does it make any sense at all to include a protocol list in the renegotiation handshake?

Yoav




_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls