On Wed, Oct 28, 2009 at 11:00:13AM -0500, Nicolas Williams wrote: > On Wed, Oct 28, 2009 at 10:18:04AM +0000, Larry Zhu wrote: > > There is a design issue in tls-unique. For vendors who implement TLS > > in a separate library, the TLS library does not by itself control the > > transport therefore it would not know if there is a new connection, so > > that the current specification is not implementable for these vendors. > > > > It would be much easier to say the following instead: > > > > The client's TLS Finished message from the first handshake of the > > session (note: TLS session, not connection, so that the channel > > binding is specific to each TLS session regardless of whether session > > resumption is used). I spoke to Jeff and I think I understand your issue, and I agree that we never meant for that interpretation. Proposed new text is below, but first... What the text says now: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the connection (note: connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used). I think we meant to say is that if you're a server, and you see a ClientHello, and you do a handshake and then receive a client Finished message, and then return a handle to the application for the resulting TLS whatever-you-call-it, then _that_ Finished message will be the channel binding, EVEN IF the client then does a second handshake (for re-keying, for authenticating the client, whatever). Similarly, if you're a client and send a ClientHello and so on and so forth and then return a handle to the application for the resulting TLS whatever-you-call-it, then the first Finished message will be the channel binding, EVEN IF the client then does a second handshake (for re-keying, for authenticating the client, whatever). The reason we used the word "connection" in the description was to avoid the possibility that in a session resumption someone might interpret tls-unique to be the client Finished message of the original connection that established the session resumption state. Changing the text to say "session" instead of "connection" now would risk creating that confusion. The key issue here is how to write the description in such a way that it is obvious to a TLS implementor in spite of the fact that the words "connection", "session" and "transport" have multiple possible meanings in the contexts where TLS is used. Here, then, is my proposed clarification: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the TLS session. (Yes, I changed "connection" to "session", followed by this:) Clarification: If a connection resumes a previous session, then the Finished message to use is that of the new session, not the one from the original session. If a session has multiple handshakes and, therefore, multiple client Finished messages, the first client Finished message of that session is the one to use as the tls-unique channel binding. From an application programming interface (API) perspective, the client's Finished message is saved in the contextual object handle that the client and server applications obtain when they initiate or resume a TLS session; later, when the applications request the tls-unique channel binding, the TLS implementation retrieves the saved first client Finished message from that context handle. Nico --
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.