Subject: [sasl] Last Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 5 Oct 2009 09:27:04 -0700 (PDT)

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
[email-masked] mailing lists by 2009-11-02. Exceptionally, 
comments may be sent to [email-masked] 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

---

From: Larry Zhu <[email-masked]>
Date: Wed, 28 Oct 2009 10:18:04 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
Sent: Monday, October 05, 2009 9:27 AM
To: IETF-Announce
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [TLS] Last Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Wed, 28 Oct 2009 14:27:04 +0100

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Larry Zhu
> Sent: 28 October, 2009 12:18
> To: [email-masked]; [email-masked]; [email-masked]
> 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.
> 
> 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 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.
> 
> sasl mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sasl

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 28 Oct 2009 15:11:28 +0100

I agree with Larry that the current definition of tls-unique is
impossible to implement in TLS libraries in the way you'd typically
want, i.e., a tls_get_tls_unique_cb() function.

However, there IS a way that TLS libraries can support the current
approach: add a callback interface to provide applications with the TLS
Finished message, and let the application handle the complexities
regarding connections vs session.

That is what I decided to do in GnuTLS, a callback like this:

  typedef void (*gnutls_finished_callback_func) (gnutls_session_t session,
						 const void *finished,
						 size_t len);
  void
  gnutls_session_set_finished_function (gnutls_session_t session,
					gnutls_finished_callback_func func);

Generally, I'm not happy with draft-altman-tls-channel-bindings so if
this is an opportunity to consider alternatives I want to remind you of
this work:

http://josefsson.org/sasl-gs2/draft-josefsson-sasl-tls-cb-02.txt

It makes sure to bind the channel binding uniquely to BOTH the current
connection and the current session.  The
draft-altman-tls-channel-bindings-07 document only binds to the current
TLS connection.  So from this perspective, my work has the same issue,
but it is different in other aspects.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 28 Oct 2009 15:24:09 +0100

> but it is different in other aspects.

This reminded me of an earlier observation, and it might be relevant to
re-iterate it here.  Consider this:

Day 1:

1. Client establish TLS anon-anon to server.
2. User authenticates using SCRAM with channel binding to the TLS
   channel
3. User/client disconnects

Day 2:

4. Client resumes the TLS anon-anon connection
5. Client rehandshake with X.509 client + server authentication
6. User authenticates using SCRAM with channel binding to the
   TLS channel
7. User/client disconnects

Day 3:

7. Client resumes the TLS session
8. Client rehandshake it as anon-anon
9. User authenticates using SCRAM with channel binding to the
   TLS channel
10. User/client disconnects

With draft-altman-tls-channel-bindings-07, the channel binding data used
in all three SCRAM authentications is the same bit sequence.  That means
there is only an indirect cryptographic binding between the SCRAM user
authentication and the X.509 client authentication.

/Simon

---

From: Larry Zhu <[email-masked]>
Date: Wed, 28 Oct 2009 10:09:58 +0000

Thanks,

--Larry

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Oct 2009 11:00:13 -0500

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
> 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 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. 
> 

Larry,

It's hard to parse your message because the words "connection" and
"transport" have multiple possible meanings in this context.

In any case we've discussed this before, and the _current_ text is what
we reached consensus on earlier.  I believe the current text says what I
think you meant to say, in your e-mail.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Oct 2009 11:33:23 -0500

> > binding is specific to each TLS session regardless of whether session

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
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 28 Oct 2009 21:49:28 +0100 (MET)

Nicolas Williams wrote:
>    channel binding.

This description/terminology about resume/previous/new/original session
is confusing and wrong.

If a TLS session is resumed, then the result is always the SAME session,
which is indicated by the use of the SAME session id (and internally,
by the use of the same underlying master secret).

A cached TLS session can be resumed quite often and simultaneously is
parallel (which leads to multiple parallel/forked sessions).

The session keys are newly re-derived for each connection and each
session resume, and they should be unique because of the client
random and server random that go into the session key derivation
of every new connection (=resumed session).

A resumed TLS session will also NOT exchange (and therefore not verify)
any certificates.

A new TLS session is created when one of
  - the client does not propose TLS session resume at all
  - the server does not agree to TLS session resumption, and
    creates and returns a new/different session id and
    performs a full handshake
  - the client performs a renegotiate for an established
    session (usually upon request from the server) and
    the server goes through a full ssl handshake.

Since the finished messages of the tls handshake cover the
client random and server random of the SSL handshake, the finished
messages are going to be unique for each connection, even for
two resumes of the same session.

>                      From an application programming interface (API)

Asking the TLS protocol stack to memorize the original finished message
sounds awkward to me.  The thing that the ssl session cache is already
memorizing for a session is the master secret, so maybe deriving something
from that would be better suited for the purpose than a requirement to
store the original finished message.

-Martin

---

From: Larry Zhu <[email-masked]>
Date: Wed, 28 Oct 2009 20:59:53 +0000

How about

   The client's TLS Finished message (note: the Finished 
   struct) in the clear text form from the first handshake of 
   the TLS session as identified by the 
   session ID in the server 
   hello message, as defined in 7.4.1.3 of RFC5246, 
    of the last handshake in the current active TLS session.

Can we label this as "tls-session-unique"? The existing deployment seems to have a different interpretation but we do not have a real usage case for that. It does not hurt to create another label just to avoid potential interoperability issues.

This seems to be the most intuitive definition and we do not have any ambiguity here.

Thanks,

--Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nicolas Williams
Sent: Wednesday, October 28, 2009 9:33 AM
To: Larry Zhu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)

What the text says now:

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Oct 2009 15:54:24 -0500

> by the use of the same underlying master secret).

Yes, I know.  That's why we had written "connection" instead of session!
But now Larry finds that confusing as well.

> A resumed TLS session will also NOT exchange (and therefore not verify)

Indeed.  But it does exchange Finished messages.  That's crucial here.

> two resumes of the same session.

Exactly.  That's what we want.

> store the original finished message.

Argh, I've managed to confuse you too.  I mean EXACTLY this: it's NOT
the client Finished message from the _session_ that is being resumed
(when one is), but the one for the connection.

Martin,

I appreciate your help, but we really need to hear from Larry, because
I'm all confused, and as a result I'm confusing you too.

Larry, can you please clarify?

Nico
--

---

From: Larry Zhu <[email-masked]>
Date: Wed, 28 Oct 2009 20:59:53 +0000

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: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 28, 2009 6:27 AM
To: Larry Zhu; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)

Larry,

Best regards,
Pasi

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Oct 2009 16:21:17 -0500

On Wed, Oct 28, 2009 at 08:59:53PM +0000, Larry Zhu wrote:
> Can we label this as "tls-session-unique"? The existing deployment
> seems to have a different interpretation but we do not have a real
> usage case for that. It does not hurt to create another label just to
> avoid potential interoperability issues.
> 

Larry and I just spoke on the phone.

The real issue is the word "connection".  Apparently RFC5246 uses it in
two senses, one of them being the-transport-layer-above-IP (i.e., TCP
for TLS and UDP for DTLS, typically), and that is confusing.

I explained to Larry that using "session" instead, as in his proposed
text above is nearly impossible to implement, because it means updating
session resumption state caches -- a very intrusive change to existing
TLS implementations.

What Larry really wants is to find a way to refer to what Microsoft's
SSPI-based implementation of TLS calls a "security context".  Advice on
what would be the best TLS-specific term for "security context" is
welcome.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 30 Oct 2009 17:36:48 -0500

I spoke at length with Larry.

His concern is that the word "conenction" might be taken to mean "TCP
connection" or "connection for the transport below TLS".

Clearly it is not reasonable to expect to extract the TLS channel
binding from the "connection for the transport below TLS"!

Larry's proposal to say "session" was only to make that confusion go
away, but that proposal is very difficult to implement (as I described
separately already).

Larry has indicated to me (and I expect will indicate on the list in
reply to this email) that he will be happy if we simply clarify that
"TLS connection" refers to the TLS state, NOT to the transport below.

Unfortunately RFC5246 does not seem to have a term by which to refer the
"TLS connection" unambiguously: "connection" is defined in the glossary
(page 80) to mean that which Larry doesn't want (underlying transport),
but then, in section 6.1 RFC5246 quite clearly uses the word
"connection" to refer to "TLS connection", not to the underlying
transport.

Thus this is a simple matter of wordsmithing.

Another problem that Larry has is that in his implementation what I call
a "TLS connection" is called a "security context", and if the
application re-handshakes (e.g., to authenticate a user) then the result
is a second security context -- we need to be extra clear that it's the
client Finished message from the _first_ "security context" that we're
after.

My proposal, then, is this:

OLD:

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.

Larry, please review.

Martin, please review.

Nico
--