Subject: Re: [Unbearable] TLSUnique is only 96 bits. Is OK?

From: John Bradley <[email-masked]>
Date: Tue, 1 Sep 2015 11:56:42 -0300

In the token binding use case the private key is the secret thing.  

The TLS unique is something known to both ends to sign over.   

There is no security property other than it being known to both ends of the connection that is being used.  I don’t think collisions are an issue.

Perhaps the authors can comment.

John B.

> On Aug 31, 2015, at 11:38 PM, Nico Williams <[email-masked]> wrote:
> 
> On Monday, August 31, 2015, Bill Cox <[email-masked] <mailto:[email-masked]>> wrote:
> > [...]
> 
> The use cases envisioned in RFC5056 are somewhat limited.  Uses of channel bindings in new ways require additional analysis.  I'll have to refresh my memory as to the token binding use...  But yes, if the threat model allows the attacker to know the change binding and to attempt many connections then yes, 96 bits behind to look short.
> 
> Nico
> -- 
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable

---

From: Nico Williams <[email-masked]>
Date: Tue, 1 Sep 2015 10:30:30 -0500

On Tue, Sep 01, 2015 at 11:56:42AM -0300, John Bradley wrote:
> > The use cases envisioned in RFC5056 are somewhat limited.  Uses of
> > channel bindings in new ways require additional analysis.  I'll have
> > to refresh my memory as to the token binding use...  But yes, if the
> > threat model allows the attacker to know the change binding and to
> > attempt many connections then yes, 96 bits behind to look short.
> 
> There is no security property other than it being known to both ends
> of the connection that is being used.  I don't think collisions are an
> issue.

The idea is that IF the cookies leak, they are of no use to attackers
because they must also possess the user agent's signing key in order to
use the leaked (stolen) cookies.

The idea for attacking tls-unique here is that if you have stolen a
bound token then you can attempt to cause or find a collision on
tls-unique values.  Since tls-unique values are only 96 bits, you have a
natural collision chance of roughly 1 in 2^48 by the birthday paradox.
If you can also force collisions (see Karthikeyan B.'s post) then you
can do better.

So collisions are an issue, and 96 bits is too little.  128 bits would
be too little, really.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Sep 2015 21:24:22 +0300

> On Sep 1, 2015, at 6:30 PM, Nico Williams <[email-masked]> wrote:
> 

Assuming you can’t, doesn’t this mean that you would need 2^48 TCP and TLS handshakes to get a better than even chance of producing a collision?  That is a far cry from producing a bunch of values locally and crunching the numbers.

---

From: Nico Williams <[email-masked]>
Date: Tue, 1 Sep 2015 13:47:34 -0500

On Tue, Sep 01, 2015 at 09:24:22PM +0300, Yoav Nir wrote:
> Assuming you can't, doesn't this mean that you would need 2^48 TCP and
> TLS handshakes to get a better than even chance of producing a
> collision?  That is a far cry from producing a bunch of values locally
> and crunching the numbers.

Yes, there's no reason to panic at this time, but we should specify a
larger replacement for tls-unique.  Several suggestions I've seen
off-list include using the keying material exporter with the extended
master secret (so as to bind the entire handshake), which will do fine
when using the EMS, but not when not, and has the advantage that the
exporter has better API support than CB.

Nico
--

---

From: Andrei Popov <[email-masked]>
Date: Tue, 1 Sep 2015 19:07:47 +0000

Yes, I think we should update the TBPROTO spec to switch from TLS-UNIQUE to RFC 5705 keying material exporters (with EMS, which was a TB requirement from the start). Unless there are objections/better ideas, I'll take a stab at it later this week.

TLS-UNIQUE issues will need to be solved separately in the TLS WG, but keying material exporters are widely supported in TLS implementations today and are still deemed secure (when used with EMS).

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Tuesday, September 1, 2015 11:48 AM
To: Yoav Nir <[email-masked]>
Cc: John Bradley <[email-masked]>; [email-masked]; Bill Cox <[email-masked]>
Subject: Re: [Unbearable] TLSUnique is only 96 bits. Is OK?

> and crunching the numbers.

Yes, there's no reason to panic at this time, but we should specify a larger replacement for tls-unique.  Several suggestions I've seen off-list include using the keying material exporter with the extended master secret (so as to bind the entire handshake), which will do fine when using the EMS, but not when not, and has the advantage that the exporter has better API support than CB.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Sep 2015 12:09:47 -0700

Andrei,

This seems reasonable. We'd discussed having a separate channel binding
for TLS 1.3, but maybe a recommendation about how to use Exporters to
generate one would be simpler

-Ekr

On Tue, Sep 1, 2015 at 12:07 PM, Andrei Popov <[email-masked]>
wrote:

> Yes, I think we should update the TBPROTO spec to switch from TLS-UNIQUE
> to RFC 5705 keying material exporters (with EMS, which was a TB requirement
> from the start). Unless there are objections/better ideas, I'll take a stab
> at it later this week.
>
> TLS-UNIQUE issues will need to be solved separately in the TLS WG, but
> keying material exporters are widely supported in TLS implementations today
> and are still deemed secure (when used with EMS).
>
> Cheers,
>
> Andrei
>
> larger replacement for tls-unique.  Several suggestions I've seen off-list
> include using the keying material exporter with the extended master secret
> (so as to bind the entire handshake), which will do fine when using the
> EMS, but not when not, and has the advantage that the exporter has better
> API support than CB.
>
> Nico
> --
>

---

From: Andrei Popov <[email-masked]>
Date: Tue, 1 Sep 2015 19:18:59 +0000

Hi Eric,

Yes, for TLS there are a number of options, a couple that come to mind are:

1.       Defining a new, secure binding and asking apps to use the new binding instead of TLS-UNIQUE;

2.       Updating the definition of TLS-UNIQUE, and negotiating the new definition (via an extension?).

Figuring this out will likely take the TLS WG some time, and then TLS stacks need to be updated and deployed. I would like to avoid blocking TB work until TLS-UNIQUE is fixed.

On the other hand, keying material exporters (with EMS) are currently defined, implemented and deployed, which makes them appealing for use in Token Binding.

Cheers,

Andrei

From: Eric Rescorla [mailto:[email-masked]]
Sent: Tuesday, September 1, 2015 12:10 PM
To: Andrei Popov <[email-masked]>
Cc: Nico Williams <[email-masked]>; Yoav Nir <[email-masked]>; John Bradley <[email-masked]>; [email-masked]; Bill Cox <[email-masked]>
Subject: Re: [Unbearable] TLSUnique is only 96 bits. Is OK?

Andrei,

-Ekr

On Tue, Sep 1, 2015 at 12:07 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Yes, I think we should update the TBPROTO spec to switch from TLS-UNIQUE to RFC 5705 keying material exporters (with EMS, which was a TB requirement from the start). Unless there are objections/better ideas, I'll take a stab at it later this week.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Nico Williams
Sent: Tuesday, September 1, 2015 11:48 AM
To: Yoav Nir <[email-masked]<mailto:[email-masked]>>
Cc: John Bradley <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Bill Cox <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] TLSUnique is only 96 bits. Is OK?

Nico
--

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

---

From: Nico Williams <[email-masked]>
Date: Tue, 1 Sep 2015 14:52:27 -0500

On Tue, Sep 01, 2015 at 07:07:47PM +0000, Andrei Popov wrote:
> Yes, I think we should update the TBPROTO spec to switch from
> TLS-UNIQUE to RFC 5705 keying material exporters (with EMS, which was
> a TB requirement from the start). Unless there are objections/better
> ideas, I'll take a stab at it later this week.
> 
> keying material exporters are widely supported in TLS implementations
> today and are still deemed secure (when used with EMS).

If we have EMS then the exporter can be used to define a new CB type
anyways, which we agree we need.  If we use the same formulation in both
case we can then get CB even in APIs that lack direct CB support, and
that's a good thing.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 1 Sep 2015 15:16:51 -0500

> 1.       Defining a new, secure binding and asking apps to use the new binding instead of TLS-UNIQUE;

Yes.

> 2.       Updating the definition of TLS-UNIQUE, and negotiating the new definition (via an extension?).

We can define a new form of tls-unique for 1.3.

Redefining it for earlier versions would be a breaking change (which a
sufficiently powerful break in tls-unique could justify) that I think is
best avoided.

We could always do both, so there's no need to hold back TB.  Just
define a new CB type for TB and later, if we want to redefine
tls-unique, we can.  The two things are orthogonal.

> On the other hand, keying material exporters (with EMS) are currently
> defined, implemented and deployed, which makes them appealing for use
> in Token Binding.

A definition of a new CB type in terms of the exporter with EMS means
you can implement it without having to add new CB type (or CB at all)
support to any TLS libraries that already have exported + EMS.

Nico
--

---

From: Andrei Popov <[email-masked]>
Date: Tue, 1 Sep 2015 20:35:41 +0000

> A definition of a new CB type in terms of the exporter with EMS means you can implement it without having to add new CB type (or CB at all) support to any TLS libraries that already have exported + EMS.

Yes, to me this looks like an implementation of option 1: new TLS-UNIQUE definition based on the exporters; apps currently using TLS-UNIQUE need to update. But this is probably best discussed in the TLS WG.

Cheers,

Andrei

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Tuesday, September 1, 2015 1:17 PM
To: Andrei Popov <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; John Bradley <[email-masked]>; [email-masked]; Yoav Nir <[email-masked]>; Bill Cox <[email-masked]>
Subject: Re: [Unbearable] TLSUnique is only 96 bits. Is OK?

Yes.

Redefining it for earlier versions would be a breaking change (which a sufficiently powerful break in tls-unique could justify) that I think is best avoided.

We could always do both, so there's no need to hold back TB.  Just define a new CB type for TB and later, if we want to redefine tls-unique, we can.  The two things are orthogonal.

> defined, implemented and deployed, which makes them appealing for use 

A definition of a new CB type in terms of the exporter with EMS means you can implement it without having to add new CB type (or CB at all) support to any TLS libraries that already have exported + EMS.

Nico
--