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

[Nico Williams <[e-mail]>]

On Fri, Jul 31, 2015 at 07:42:12PM +0300, Ilari Liusvaara wrote:
> 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. :-/

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.)

> 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.

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

> (TLS-Exporter values already look to be secret and connection
> 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.

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

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
--