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
--
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
