On Wed, Nov 04, 2009 at 04:18:44PM +0100, Simon Josefsson wrote: > <Pasi.Eronen at nokia.com> writes: > > > Can you check if the latest text proposals (Nico's email on > > October 30th, starting "I spoke at length with Larry", and > > my email earlier today) make the situation clearer? > > I have the same question as Martin Rex: what is the actual semantic that > is wanted? I thought I understood what was intended, but given this > discussion my understanding of what was intended may have been wrong. The desired semantic is that tls-unique channel bindings are a channel binding in the RFC5056 sense, for a "TLS channel", with this particular feature (from the I-D): o Channel binding type: unique (which RFC5056 defines). Was this not utterly clear already? How could it not have been? The only possible point of contention from the above description is just what a "TLS channel" might be. And the only reasons for that are: - RFC5246 and predecessors don't define a name for what we've been calling a "TLS connection"; - Session resumption might cause someone to be confused and think that tls-unique refers to the client's Finished message from the resumed session; - Re-negotiation might cause someone to be confused and think that tls-unique refers to the client's Finished message from the re-negotiated "TLS connection". Let's dispose of these for once and for all: - We shall use "TLS connection" to refer to the TLS state created by an exchange beginning with a Client Hello message, followed by a TLS handshake sequence (which involves a ServerHello, a variety of optional messages such as Certificate, and ends in an optional ChangeCipherSpec message exchange) followed by an exchange of Finished messages. - Session resumption establishes new state as per the previous definition of "TLS connection", therefore it establishes a new "TLS connection", even though session resumption does NOT establish a new session. Therefore, the tls-unique channel binding for a "TLS connection" that resumes a session, MUST be the client's Finished message from the new connection, not the old session. - Re-negotiation consists of initiating a new "TLS connection" while using another "TLS connection" record layer for integrity (and usually also confidentiality) protection of the re-negotiation. As such re-negotiation creates a new "TLS connection". In this case want the tls-unique channel binding to be used by the application to be that of the first "TLS connection", that is, the one whose ClientHello and handshake were not protected by any other "TLS connection". (It follows that even if the client does N re-negotiations, where N > 2, we still want the application to use the tls-unique channel binding of the first "TLS connection", the one whose handshake was not protected by any other "TLS connection".) Therefore a "TLS channel" is really: a "TLS connection", as defined above, whose handshake was not protected by any other "TLS connection". This is a significantly more rigorous description than the ones we've discussed so far. Do you agree that it's air-tight? Should I propose new text that adds the above definitions of "TLS connection" and "TLS channel"? I think I should, so I will, shortly. Nico --
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.