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

From: Martin Rex <[email-masked]>
Date: Sat, 6 Nov 2010 01:00:29 +0100 (MET)

Simon Josefsson wrote:
> 
> 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've also started adding code for tls-unique channel bindings and
now I'm also wondering about this description:

rfc5929 says

"(note: the Finished struct, not the TLS record layer message containing it)"

which, according to rfc-5246 looks like this:

http://tools.ietf.org/html/rfc5246#section-7.4.9

   Structure of this message:

      struct {
          opaque verify_data[verify_data_length];
      } Finished;

      verify_data
         PRF(master_secret, finished_label, Hash(handshake_messages))
            [0..verify_data_length-1];

What puzzles me now:

rfc5929 clearly says "Finished struct", which differs from the
verify_data as used by rfc5246 (TLS extension RI) in that
it WILL include the length field of the verify_data opaque vector.

If there had been any mentioning of the CB sizes for tls-unique, similar
to rfc5746 (12 octets for TLSv1.x and existing cipher suites,
36 octets for SSLv3), then I would not be wondering whether this
spec really means what it says.

What size does your tls-unique CB have for TLSv1.x?  12 or 13 octets?

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 06 Nov 2010 10:46:49 +0100

> What size does your tls-unique CB have for TLSv1.x?  12 or 13 octets?

Sigh.  I used 12 octets, but your interpretation suggests 13 octets even
though that is silly.  My new API is not in any stable GnuTLS release,
so there is still time to fix it.

Were anyone able to interop test against the Microsoft implementation
that were the justification to change the definition?

I'd love to do interop testing with someone else, to feel more confident
in the output.  I do support both TLSv1 and SSLv3 Finished messages, but
I'm striping the initial length octet.  I'll change that if there is
consensus on the interpretation.

/Simon

---

From: Jeffrey Altman <[email-masked]>
Date: Sat, 06 Nov 2010 08:03:32 -0400

> consensus on the interpretation.

The original implementation of TLS unique channel bindings comes from
the Telnet TLS work from more than a decade ago.  That was implemented
using OpenSSL which provides the following APIs:

/* Obtain latest Finished message
*   -- that we sent (SSL_get_finished)
*   -- that we expected from peer (SSL_get_peer_finished).
* Returns length (0 == no Finished so far), copies up to 'count' bytes. */
size_t SSL_get_finished(const SSL *s, void *buf, size_t count);
size_t SSL_get_peer_finished(const SSL *s, void *buf, size_t count);

The returned buffer contains 36 octets for SSL3 and 12 octets for
TLS1.x.  OpenSSL supports finished messages up to 128 octets in length.

Jeffrey Altman

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 06 Nov 2010 11:53:17 +0100

> it WILL include the length field of the verify_data opaque vector.

Does verify_data[] have a length field? It is not a variable length
vector to require length.

regards,
Nikos

---

From: Marsh Ray <[email-masked]>
Date: Sat, 06 Nov 2010 13:14:12 -0500

> vector to require length.

http://tools.ietf.org/html/rfc5246
> 1.2.  Major Differences from TLS 1.1
>    -  Verify_data length now depends on the cipher suite (default is
>       still 12).

In theory, it's variable starting with TLS 1.2. Last I checked it seemed 
like all cipher suites still define it as 12.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 06 Nov 2010 11:30:07 -0700

A Finished message does not have a length byte, even in TLS 1.2.  Square
brackets in the definition mean the data is a fixed size.  TLS 1.2 does
allow a cipher suite to change the size of the verify_data to something
other than 12, but that does not mean a length byte is included in the
Finished message.  Angle brackets would have been used in the definition
if that were the case.

Mike

---

From: Martin Rex <[email-masked]>
Date: Mon, 8 Nov 2010 14:45:15 +0100 (MET)

Michael D'Errico wrote:
> Martin Rex wrote:

*Blush*.

OK, thanks for the guidance.

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 09 Nov 2010 12:11:03 +0100

> OK, thanks for the guidance.

Interop testing of the tls-unique CB would still be useful, I believe.
Is anyone interested in this?

/Simon

---

From: Dave Cridland <[email-masked]>
Date: Tue, 09 Nov 2010 11:22:19 +0000

> Is anyone interested in this?

Yes, I've a client that should, in principle, do this.

If you run up a server running IMAP, SMTP, ACAP, or XMPP, I can talk  
those.

(I would warn I'm quite busy, so there's no point in rushing.)

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade