Re: [TLS] comments on draft-ietf-tls-applayerprotoneg-00

[Andrei Popov <[e-mail]>]

Hi Nikos,

* Section 6 “IANA Considerations” says:

… We propose that this new registry be created in a new page entitled:
"Application Layer Protocol Negotiation (ALPN) Protocol IDs" beneath
the existing heading of "Transport Layer Security (TLS)".

Protocol IDs are first introduced in section 3.1 “The Application Layer Protocol Negotiation Extension”. Here we can add a reference to section 6 to make this more clear.

* In ALPN, the server cannot select more than one protocol (see sections 3.1 and 3.2). The reason the server is sending a protocol_name_list is that keeping client-side “extension_data” structure identical to the server-side “extension_data” structure simplifies both the documentation and the implementation.

* The text about the hash calculations was intended to make it absolutely clear that the content of the new extension is included in the hash calculations, and avoid any ambiguity. The need for this clarification arises from the fact that ALPN, unlike many other TLS extensions, negotiates parameters that have nothing to do with the TLS protocol itself.

Thanks,

Andrei

From: Nikos Mavrogiannopoulos [mailto:[e-mail]]
Sent: Wednesday, April 10, 2013 1:17 AM
To: [e-mail]; [e-mail]; Andrei Popov
Subject: comments on draft-ietf-tls-applayerprotoneg-00

Hello,
 Some comments on the ALPN document.
* At some point the document explains the term Protocols as: "are  named by IANA registered, opaque, non-empty byte strings."
This is not very explanatory. The first question that arises, is which IANA registry are these registered at? By reading the IANA considerations section I see a new registry being created with protocol entries, so at that point I can assume that this is the IANA registry intended, or not? Anyway I think the text should clarify that the IANA registry it refers to is defined in the same document.

* In section 3.1, the server replies with the same extension and sends a ProtocolNameList containing a single Protocol. Why is then a list sent by the server? Why not send a single Protocol instead? Is there any use case where the client would accept more than one protocols? In that case should clients be prepared for servers that send more than one protocols?

* In the same section it is mentioned: "The additional content associated with this extension MUST be included in the hash calculations associated with the "Finished" messages.". Why is that mentioned at all? Is there an option in TLS not to include that data in the TLS finished message hashes?

regards,
Nikos