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

Hi Pasi, 

Thanks for allowing me to expand. A quick summary is that the tls-unique definition hinges on an ambiguous notation of "connection", and that is unnecessary if not harmful. 

To show why we should look at RFC5246 first. Please allow a disclaimer first too. The following information is provided in order to demonstrate we can make this better or over specified thus leave with no ambiguity therefore improve interoperability.

On page 39 of RFC 5246, we have the following text that describes the session id in the client hello message:

   The session identifier MAY be from an earlier connection,
   this connection, or from another currently active connection.

This suggests that a connection can be associated with multiple sessions (as identified by "session IDs"). But then on page 79, we have the following text

   Every connection is associated with one session.

This seems to suggest a connection can only have one session (as identified by a session ID). On page 81, we have the following text:

    Sessions are used to avoid the expensive negotiation of new security parameters for each connection.

Which seems to suggest that a session is identified by a session id. Do we have a real inconsistency here? 

With that it gets worse if we read the text on page 36:

   The server then checks its session cache for a match.
   If a match is found, and the server is willing to re-establish the
   connection under the specified session state, it will send a
   ServerHello with the same Session ID value.

Let's note the words "re-establish the connection" used here. It seems to suggest that in a TLS session resumption, we are merely re-establishing a previous connection. There are evidences that suggest different interpretations exist as the recent responses from Joseph clearly demonstrated.

Now the reader is left to wonder what really identifies a connection? Does an unencrypted hello really demarcate a new connection as you suggested? If we follow the path you suggested, it is desirable?

If we interpret that a connection is one in the transport layer, the TLS library does not know and should not care. In that case, it would have the problem I alluded earlier.

Furthermore the current definition would not work with DTLS though if we throw out the notion of "connection", say for example use the TLS session or the last handshake, we can reuse the work for DTLS.

I will discuss with the rest of the editor team and we should come up with a recommendation for how to address this issue. Thanks,

--Larry

-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] 
Sent: Wednesday, October 28, 2009 6:27 AM
To: Larry Zhu; channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org
Subject: RE: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)

Larry,

Could you elaborate a bit about your first paragraph?  

Certainly the TLS library knows when there's a new connection, because
it receives (on the server) or sends (on the client) an unencrypted 
ClientHello message?

Best regards,
Pasi

> -----Original Message-----
> From: sasl-bounces@ietf.org [mailto:sasl-bounces@ietf.org] On Behalf Of
> ext Larry Zhu
> Sent: 28 October, 2009 12:18
> To: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org
> Subject: Re: [sasl] lasgt call comments (st Call: draft-altman-tls-
> channel-bindings (Channel Bindings for TLS) to Proposed Standard)
> 
> 
> 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).
> 
> And the updated text does reflect what has been deployed for tls-
> unique.
> 
> I would like to raise a red flag now. Needless to say that I will start
> a discussion with the responsible AD and the rest of the editors of
> this ID to fix this issue, and do so based on consensus.
> 
> Pasi, please consider this issue blocking for now.
> 
> Thanks,
> 
> --Larry
> 
> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> The IESG
> Sent: Monday, October 05, 2009 9:27 AM
> To: IETF-Announce
> Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org
> Subject: [TLS] Last Call: draft-altman-tls-channel-bindings (Channel
> Bindings for TLS) to Proposed Standard
> 
> The IESG has received a request from an individual submitter to
> consider
> the following document:
> 
> - 'Channel Bindings for TLS '
>    <draft-altman-tls-channel-bindings-07.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf@ietf.org mailing lists by 2009-11-02. Exceptionally,
> comments may be sent to iesg@ietf.org instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings-
> 07.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
> =15087&rfc_flag=0
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> sasl mailing list
> sasl@ietf.org
> https://www.ietf.org/mailman/listinfo/sasl