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

[Dean Anderson <[e-mail]>]

On Wed, 3 Feb 2010, Eric Rescorla wrote:

> Moreover, the the purpose of the random values is *not* to add extra
> cryptographic strength, since they're not secret. Rather, it's to
> ensure uniqueness of the handshake master secret even if the PMS is
> repeated. However, the bound here is just the collision bound for the
> random values, which doesn't require anything like 224 bits.
> 
> I'm not really against this extension, but I'm not aware of any
> coherent security argument for it.

Thinking it over, I have some concerns about the security implications
on the master_secret calculation.  I didn't think about this until Paul
Hoffman wanted to alter and increase the size the client and server
random numbers. I have to dispute that the client random and server
random need not be 'cryptographically random' instead of known but
random values. And I have a concern that they are not secret.  The only
entropy in the calculation is the pre_master_secret.

First, I am concerned that the entropy of the pre_master_secret is
reduced by presence of the revealed random number.  In the absence of a
perfect random number generator, the pre_master_secret and the random
number are not independent.  I think the rule of thumb is never to give
out random numbers to potential attackers if your random numbers aren't
perfectly random, and it's hard in practice to have perfectly random
numbers. So this seems like a crack in security in many implementations
that could potentially be exploited.

Second, if the pre_master_secret is the only real secret, while the
client random and server random are known, then more of the input to the
PRF is known, and thus the output of the PRF must also be more
predictable (at least due to less entropy in the dependent
pre_master_secret).  Changing the client random and/or server random to
be even larger known values seems (intuitively anyway--I'm not sure this
is the case) to impose an even more negative impact on the
predictabilitiy of the PRF output.  It seems to me like that might be a
security vulnerability, too. It has been reported that AES may be
significantly weaker than expected when some bits of the key are known.

Paul Hoffman's draft is only outside the charter because of the
admonition "In the preparation of TLS 1.2, the WG will attempt to avoid
gratuitous changes to TLS 1.1.". However, the master_secret calculation
and changes to it are in scope for the TLS working group--it is not the
case that changes are out of scope, but that the Working Group is under
instructions not to make "gratuitous changes". It seems to me that
Paul's draft circumvents this instruction.

So I think the WG should look into the calculation of the master_secret
for security weaknesses. If there is indeed a security issue, fixing
that would not be a "gratuitous change".

		--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494