Re: [TLS] New drafts: adding input to the TLS master secret

[Martin Rex <[e-mail]>]

Brian Smith wrote:
> 
> Any  extensions that contain non-trivial amounts of data and/or possibly
> sensitive information should be transmitted after change_cipher_spec
> messages--not in hello messages--whenever practical. When a hello extension
> does contain non-trivial amounts of information or sensitive information,
> then the security considerations section of its specification should explain
> why the extension cannot be moved to after the change_cipher_spec messages. 

As far as I understand, the proposals are about adding entropy into
the TLS MasterSecret computation, not about adding sensitive information.

When using an extension, that additional entropy could also be used
for deriving new keying material (connection parameters) on
TLS session resumption (because these handshake messages do exist
in the abbreviated handshake), but since the existing proposal are
specific about MasterSecret computation, that seems not to be an
issue here (session resumption does _not_ change the session's
MasterSecret).

Currently, the entropy depends on the ClientHello.Random
and ServerHello.Random (28 bytes for use available for each peer),
plus the result of the keyExchange algorithm (with plain RSA ciphersuites,
the client gets to chose/generate all that data/randomness)

In the existing TLS architecture, it is not allowed to send
any message between ChangeCipherSpec and Finished, and Finished
is also the very first message protected under the connection
parameters for the newly created TLS session based on the
sessions MasterSecret.

Before the transmission of the ClientKeyExchange handshake message,
there are no common cryptographic parameters that could be used
for protection at all.

If you wanted to get some sensitive data transfered within the
initial TLS handshake, it would have to be done after ClientKeyExchange
(and if we ever come up with a scheme to protect the client identity
in TLS already in the initial handshake, the (client's) Certificate
and ClientKeyExchange handshake message would have to change their
places in order from where they are currently sent.


What puzzles me a little is that why the existing 28 bytes of
Random in both Hello handshake messages should not be sufficient
for the purpose.  Is there problem in "compressing" large amount
of low-entropy data into that 28-byte of randomness (lack of
suitable compression function)?


Technically, I could conceive that a TLS implementation offers to
application callers a possibility to supply extra entropy that the
TLS implementation will "consume" when producing the 28 bytes
of Hello.Random.  That could be done immediately at the discretion
of every TLS implementation and not require any protocol changes
at all.


-Martin