Subject: Re: [TLS] Computation of static secret in anonymous DH

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 31 Jul 2015 19:42:12 +0300

On Fri, Jun 26, 2015 at 01:41:29PM -0500, Nico Williams wrote:
> 
> tls-unique depends on the Finished message strongly binding the entire
> transcript up to that point.  I find this elegant (despite the
> resumption problem, which anyways, should be fixed by the session hash)
> and easy to understand and analyze.
> 
> If the Finished message no longer has this property in 1.3 then that's a
> problem for tls-unique, and we'd have to fix one or the other.  Surely
> 1.3 will have some handshake message that binds the transcript, and why
> that wouldn't be the Finished message is beyond me (but I am missing a
> lot of the 1.3 context, so please forgive and inform me).

Also, it turns out some are assuming tls-unique is both connection nonce
and secret value. :-/

I don't think the present construct for Finished values is appropriate
for such values, which means one would have to redefine tls-unique
so it meets the need.

(TLS-Exporter values already look to be secret and connection
nonces, and I have already seen stuff relying on both properties).

Basically, the value needs to derive from both "master secret" (to make
it secret) and session hash /w configs (to make it connection
nonce).

-Ilari

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Jul 2015 11:55:48 -0500

> Also, it turns out some are assuming tls-unique is both connection nonce

RFC5929 quite rightly says not to do that.

Do you have examples of apps doing this?

(The Finished message is generally sent encrypted, so that's not that
terrible an assumption.)

> for such values, which means one would have to redefine tls-unique

I'd rather avoid this unless we really need to.  Examples of
applications mis-using tls-unique would be nice.

> nonces, and I have already seen stuff relying on both properties).

A proper TLS-Exporter can be used (was intended to be used!) as secret
and whatever "connection nonces" are.

> it secret) and session hash /w configs (to make it connection

Which Finished messages do!

The only problem with Finished messages as secrets is that the cipher
used might not provide confidentiality protection.  (Again, I'm not
endorsing the use of tls-unique as a secret.)  If we have no such
ciphersuites left in TLS 1.3...

Nico
--