Subject: [kitten] RFC 5929 tls-unique clarification?

From: Simon Josefsson <[email-masked]>
Date: Fri, 15 Oct 2010 14:12:43 +0200

I'm implementing an API for RFC 5929 in GnuTLS and I'm having some
troubles with the specification.  Section 3.1 says:

   Description: The first TLS Finished message sent (note: the Finished
   struct, not the TLS record layer message containing it) in the most
   recent TLS handshake of the TLS connection being bound to (note: TLS
   connection, not session, so that the channel binding is specific to
   each connection regardless of whether session resumption is used).

I don't follow the need for a distinction between connection and session
here -- a TLS session resumption consists of a new TLS handshake and it
exchanges new Finished messages.

To be precise, is it the case that, for a resumed TLS session, the
tls-unique CB is

1) the first TLS Finished message sent in the initial full TLS
handshake?

or

2) the first TLS Finished message sent in the abbreviated TLS handshake?

In the former case, the text appears to be wrong because it refers to
the most recent TLS handshake and not the initial full TLS handshake,
and in the second case the distinction between session and connection
does not seem to matter because the tls-unique CB data is always using
the first Finished message exchanged in the latest TLS handshake?

/Simon

---

From: Martin Rex <[email-masked]>
Date: Fri, 15 Oct 2010 19:45:54 +0200 (MEST)

> 2) the first TLS Finished message sent in the abbreviated TLS handshake?

Without having checked implementations, only 2) makes sense.

Binding to the first Finished message that is exchanged helps in
piggy-backing data onto that Finished message (e.g. TLS false start).

But instead of channel bindings, the published TLS CB is about
"connection state binding", because the binding changes
with every renegotiation on existing channel. 

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Oct 2010 13:39:51 -0500

> exchanges new Finished messages.

Some people thought that we needed to be clear about this in case
someone thought that the CB for a TLS connection were those of the
handshake that created the session.  You can see that that would be bad.

> 2) the first TLS Finished message sent in the abbreviated TLS handshake?

(2).

> the first Finished message exchanged in the latest TLS handshake?

See above.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 15 Oct 2010 22:25:33 +0200

> handshake that created the session.  You can see that that would be bad.

Yes, but even after multiple re-readings I was still confused what the
text really said.

>> 2) the first TLS Finished message sent in the abbreviated TLS handshake?

Good.  That's what I implemented.  For reference, the API we decided on
is this one:

http://www.gnu.org/software/gnutls/devel/manual/html_node/Channel-Bindings.html
http://www.gnu.org/software/gnutls/devel/manual/html_node/Core-functions.html#gnutls_005fsession_005fchannel_005fbinding

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Oct 2010 16:05:37 -0500

> Yes, but even after multiple re-readings I was still confused what the

Sigh.  It took a lot of negotiation to get text that made everyone
happy.  And it's still not good enough?  But I think it's clear...
Maybe it's just me.

> Good.  That's what I implemented.  For reference, the API we decided on

Good.  (1) would be really difficult to implement, and for what
benefit? (none, really).

> http://www.gnu.org/software/gnutls/devel/manual/html_node/Core-functions.html#gnutls_005fsession_005fchannel_005fbinding

Awesome!

Do you also support tls-server-end-point?

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 15 Oct 2010 23:22:06 +0200

> happy.  And it's still not good enough?  But I think it's clear...

Describing a couple of different TLS flows (e.g., one normal, one
resumed, one renegotiated) and what the binding should be in each case
would have helped me.  But the RFC is already published so there is no
point now.

> Good.  (1) would be really difficult to implement, and for what

It wouldn't be that difficult to implement (1), just store the old
finished messages together with the session data.  One benefit would be
that there is no renegotiation synchronization problem.  I dislike it
from a security perspective though, since I really want user
authentication to be bound to the latest TLS handshake and not an
earlier one.

> Do you also support tls-server-end-point?

Nope, but it should be possibly to implement using already existing APIs
anyway.  Still, it is on my todo list.

One concern with the tls-server-end-point definition is that I'm not
sure what to do if the local code don't implement the hash function used
by the server certificate.  Hopefully this won't be common in practice
though.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Oct 2010 17:03:03 -0500

> would have helped me.  But the RFC is already published so there is no

That would have made it quite lengthy, but, yes, that might have helped.
Brevity, when concise, helps though, and we thought we had both
attributes for the text.

> by the server certificate.  Hopefully this won't be common in practice

How can you verify the server cert if you don't have an implementation
of the server cert's signature algorithm's hash algorithm??
(Answer: PKIX and TLS are different layers, and you might not have an
implementation of that hash alg available to the TLS stack).

Anyways, that brings up another issue: the application may negotiate CB
types, for all we know, so it's important to know what CB types will be
available.  You might want to add a function that tells you what CB
types are available for a given session.  (Well, OK, the app could just
ask for all CB types and then determine which are available that way.)

Also, you might want an API by which to tell TLS which CB type the app
will need, that way the TLS library can throw away CB data that won't be
needed.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 16 Oct 2010 09:07:39 +0200

> implementation of that hash alg available to the TLS stack).

Yes, and there are other potential answers too -- e.g., no PKIX
validation at all but instead trust SCRAM with channel binding to
protect against MITM, or validation of PKIX material by a hard coded
fingerprint or through a Keyassure approach.

> will need, that way the TLS library can throw away CB data that won't be

Right it now it is inexpensive to store the tls-unique data, and the
tls-server-end-point CB is possible to compute without storing anything
more than what is already stored by the library.  So I'll considering
adding those APIs when I see a real practical need.  Adding and
maintaining new APIs has a high cost, so I don't want to add anything
that isn't needed today.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 17 Oct 2010 06:58:03 +0100

>would have helped me.  But the RFC is already published so there is no
Sigh. You are right about that.

We can submit an erratum. While it is not a substitute for an updated 
document, it can help implementors.