Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard))

[<[e-mail]>]

Nicolas Williams wrote:

> My proposal, then, is this:
> 
> OLD:
> 
>    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).
> 
> NEW:
> 
>    Description: The client's TLS Finished message (note: the
>    Finished struct) from the first handshake of the application's
>    TLS connection.
> 
>    NOTES:
> 
>    a) If a session is resumed, the client's TLS Finished message from
>       the session resumption handshake is to be used;
> 
>    b) If a client does multiple TLS handshakes in sequence, each
>       protected by the previous one, then the client's TLS Finished
>       message from the first/outermost TLS connection is to be used;
> 
>    c) By "TLS connection" we refer to the TLS connection state, not to
>       any notion of connection of any underlying transport protocols
>       (such as TCP, UDP, SCTP, etcetera).
> 
> I'm not sure that we can make it any clearer.

In any case, I guess we agree that we're referring to the latest TLS
handshake sent in clear (with TLS_NULL_WITH_NULL_NULL state)?

Could we somehow refer to this? Perhaps:

  Note: We define a new "TLS connection" to start when the client
  sends an unencrypted (TLS_NULL_WITH_NULL_NULL cipher suite) Client
  Hello message (which can lead to either a full handshake, or
  resuming a session). Renegotiation (sending a Client Hello protected
  under some other cipher suite) does not start a new "TLS connection".  
  Note that this is separate from any notion of "connection", if any, 
  in the underlying transport protocol (such as TCP or UDP).

(Is this consistent with what the existing implementations do?)

Best regards,
Pasi