Subject: [Unbearable] clarification question (was Re: Clarifying Token Binding behavior with renegotiation)

From: Brian Campbell <[email-masked]>
Date: Thu, 13 Oct 2016 14:06:28 -0600

Practically isn't the EKM obtained from the PRF and master secret of the
TLS session and the client and server random values are from the handshake
that set up the current TLS connection?

That's the behavior I've seen with Chrome. When multiple connections are
established via abbreviated handshake, each connection has a different EKM
for TB because the client and server random values differ.

On Fri, Oct 7, 2016 at 5:52 PM, Nick Harper <[email-masked]> wrote:

>
> Section 3.3 of TBPROTO specifies that the EKM is obtained from the current
> current TLS connection, but RFC 5705 states that the exporter is associated
> with a TLS session (more specifically, a set of SecurityParameters).
>
>

---

From: Nick Harper <[email-masked]>
Date: Thu, 13 Oct 2016 13:21:36 -0700

The EKM is computed from the SecurityParameters, which include the client
and server random values from the latest handshake on the TLS connection.
(The EKM definition also includes SecurityParameters.master_secret, which
is from the TLS session.) I think there's nomenclature confusion here,
since TLS session commonly means the thing with the master secret that can
be resumed. Perhaps it would have been more accurate to say that an EKM is
dependent on both the TLS connection and the TLS session?

You're correct that when a TLS session is resumed multiple times, each
connection for resumption has a different EKM.

On Thu, Oct 13, 2016 at 1:06 PM, Brian Campbell <[email-masked]>
wrote:

>> Section 3.3 of TBPROTO specifies that the EKM is obtained from the
>> current current TLS connection, but RFC 5705 states that the exporter is
>> associated with a TLS session (more specifically, a set of
>> SecurityParameters).
>>
>>
>
>
>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 13 Oct 2016 20:44:55 +0000

Ø  Practically isn't the EKM obtained from the PRF and master secret of the TLS session and the client and server random values are from the handshake that set up the current TLS connection?
Correct, the EKM is different in each resumed TLS connection, and in each renegotiated TLS session. This is why we can use EKM to prove possession of the TB keys☺.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, October 13, 2016 1:06 PM
To: Nick Harper <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: [Unbearable] clarification question (was Re: Clarifying Token Binding behavior with renegotiation)

Practically isn't the EKM obtained from the PRF and master secret of the TLS session and the client and server random values are from the handshake that set up the current TLS connection?
That's the behavior I've seen with Chrome. When multiple connections are established via abbreviated handshake, each connection has a different EKM for TB because the client and server random values differ.

On Fri, Oct 7, 2016 at 5:52 PM, Nick Harper <[email-masked]<mailto:[email-masked]>> wrote:

Section 3.3 of TBPROTO specifies that the EKM is obtained from the current current TLS connection, but RFC 5705 states that the exporter is associated with a TLS session (more specifically, a set of SecurityParameters).

---

From: Brian Campbell <[email-masked]>
Date: Thu, 13 Oct 2016 14:55:03 -0600

Thanks Nick. The question was more of just a sanity check on my part. The
nomenclature is confusing. At least for someone like myself who is
unfamiliar with the details of TLS. I just wanted to reconcile the behavior
I've observed with what you'd said to make sure I wasn't off base.

On Thu, Oct 13, 2016 at 2:21 PM, Nick Harper <[email-masked]> wrote:

> On Thu, Oct 13, 2016 at 1:06 PM, Brian Campbell <
> [email-masked]> wrote:
>