On 1/30/2013 7:15 PM, Viktor Dukhovni wrote:
On Wed, Jan 30, 2013 at 07:03:09PM +0100, Jakob Bohm wrote:
You don't, but, you shold instead obtain the "tls-unique" channel
binding data ( https://tools.ietf.org/html/rfc5929#section-3 ) and
run the result through a KDF (HKDF should work well) on both ends
to obtain a suitable key for a symmetric algorithm of your choice.
Sorry, not such a good idea.
As I read RFC5929 and the TLS 1.2 RFC, it seems that despite some
vaguely promising language in RFC5929, the tls-unique value is *not*
suitable as the basis of an encryption key for the following
reasons:
1. It is quite vague (underspecified) if and when the form of the
finished message used as the tls-unique value is A) sent in the clear
B) The already encrypted form of the message as sent over the
network or C) The plaintext passed to the TLS encryption mechanism
before transmission. In interpretation A and B the value is known
to any attackers, while in interpretation C it is known to attackers
only if the negotiated TLS encryption is NULL or weak.
The finished message is always sent (by both parties) after
ChangeCipherSpec, and thus always encrypted, provided the handshake
did not negotiate an eNULL bulk cipher. This is explicitly stated
the TLS RFCs.
In the basic non-renegotiation form of a TLS connection, the "Finished"
messages are the only handshake messages that are encrypted
("Protected"). Different descriptions of the protocol may thus (with
no change in meaning) refer to the encryption of that message to be
either part of the message or part of its framing.
Unfortunately neither the tls-unique spec at
<https://tools.ietf.org/html/rfc5929#section-3.1>
nor version 1.2 of the TLS spec at
<https://tools.ietf.org/html/rfc5246#section-7.4.9>
specify (without a search of all other document parts) if "the
Finished struct, not the TLS record layer message containing it"
refers to the encrypted or unencrypted message, hence the confusion.
Adding an appropriate adjective such as "unencrypted" or "plaintext"
to this phrase in RFC5929 would have avoided the confusion and risk
of incorrect implementations (remember the HTTP "deflate" debacle
caused by similar vagueness).
2. The TLS 1.2 RFC seems clear that the raw input tls-unique value
will often be only 12 bytes (96 bits) which is not enough input to
generate a 128 bit or stronger encryption key, no matter how clever
the KDF.
This is fair, the tls-unique value is in practice only 96 bits. And
indeed its intended use is channel-binding with GSSAPI, ...
If 96-bits is not enough, one needs to get at the master secret
on both sides, and run that through a KDF together with client
and server random plus a suitable application-specific salt.
Thanks, agreed.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
