Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random

[Marsh Ray <[e-mail]>]

On 4/22/2010 9:29 AM, Paul Hoffman wrote:
> At 12:51 AM +0200 4/22/10, Simon Josefsson wrote:
>> In which environments is the extension useful?
>>
>> The only motivation in the document that I can find is this:
>>
>>  In some application environments, it is desirable to have the client
>>  and/or the server be able to input more random material in the master
>>  key calculation than is allowed by the fixed-length Random value.
>>
>> I believe more justification than that is required for Proposed
>> Standard.

I too do not feel that this proposed Proposed Standard is a good
candidate for last call.

>> In particular, what I'd like to see is references to some application
>> environments where the extension is desirable, and the rationale why it
>> is desirable in that environment.
>>
>> Without a rationale for when the extension is useful, it is impossible
>> for implementers to know when use of this extension is warranted or not.
> 
> The environment I described in the earlier thread is TLS with
> Diffie-Hellman. I thought that saying that was sufficient, but I guess
> it wasn't.
> 
> In Diffie-Hellman key establishment with static keys, even if the PRNG
> of one side is bad, the resulting pre-master secret is still sound.

The RFCs state "TLS requires a cryptographically secure pseudorandom
number generator (PRNG). Care must be taken in designing and seeding
PRNGs." Clearly the intent here is a TLS implementation requires a
cryptographically secure true RNG, presumably built from a PRNG
initialized with sufficient entropy. Thus, there is no such such thing
as a TLS implementation without a good PRNG.

Insofar as it is the only justification for the proposed extension,
draft-hoffman-tls-additional-random-ext would appear to introduce an
endpoint-sans-entropy configuration as a supported feature of the
protocol. I don't think that could be cleanly retrofitted into the TLS
protocol at this stage.

The endpoint-sans-entropy role would have to be negotiated but AFAICT no
mechanism for doing this has been proposed. Obviously it would be a bad
thing if both endpoints thought they could be the one without a working RNG!

This negotiation would need to be strongly authenticated. Currently,
most TLS negotiated parameters (e.g. version, ciphers and macs, renego)
are exchanged in the hello messages. These are presumed by the endpoints
to not be modified by an attacker while they are used during the
handshake. Receipt of the valid Finished message retroactively
authenticates (*danger*danger*) the parameters exchanged in the hello
messages.

So what prevents the attacker from forging the Finished messages? Only
his lack of access to the MAC_secrets. (We have to assume he's
downgraded the cipher to null or something he can break.) These are
generated from the key block using master_secret, client_random, and
server_random as inputs.

Any proposed mechanism for negotiating which of the endpoints is the one
that is allowed to have a predictable RNG must be able to securely
authenticate without benefit of the client_random and server_random
inputs. The attacker may be telling both sides "hey don't bother sending
any entropy on this handshake I've got it covered".

That leaves only the master_secret input, how is it calculated? Well, it
comes from the premaster_secret and also the client_random and
server_random inputs, but again they must be assumed to now be
untrustworthy.

In the case of static DH, the premaster_secret is always the same. So
the attacker can replay a previous random to the side(s) with the
predictable RNG and arrange for this second handshake to appear to
complete successfully and re-use exactly the same keys, IVs, and
MAC_secrets as before.

But he doesn't have to generate the same Finished message. The attacker
can include some unrecognized extension with crafted data in one or both
of the hellos. It'll be ignored by the endpoint and it doesn't affect
key generation but it will change the finished message.

Now that the attacker has fixed the key and IV, he can perform
chosen-plaintext attacks against the cipher (or worse).

> Neither side knows whether or not the PRNG of the other side is bad, so
> each side wants to supply sufficient randomness for the master secret
> even if the other side's PRNG is bad.

Without this extension, each side can supply between 224 and 256 bits of
entropy, depending on how inaccurate you want to get with the
gmt_unix_time parameter. The PRF which expands these bits has multiple
layers of redundancy and perhaps even overkill (but in a good way).
"224 bits ought to be enough for anybody". :-)

Even an offline birthday attack on something that size is likely to be
forever impractical.

I'm all for adding entropy to RNGs in general. But in this case does not
sound to me like a good tradeoff to spend any additional protocol
complexity just to contributing more of it in effectively the same
manner as the current 224 bits.

> If a side with a bad PRNG adds its
> own input, it doesn't hurt the randomness of the result, but a side with
> a good PRNG can bring up the amount of randomness.

Where it hurts is when an implementation's security analysis depends on
that effect.

> I did not want to list this as the justification because there may be
> other reasons to use the extension, and I don't want readers to think
> that this is the only one. For example, future types of TLS key
> establishment might have similar properties as static-static
> Diffie-Hellman.

The problem is that in TLS these things are negotiated in the handshake
and the attacker gets to choose most of the inputs into the negotiation
up until the Finished messages are exchanged and validated. So the
attacker gets his choice of the _weakest_ of all supported key exchange
and MAC schemes of the client and server (individually) in attacking the
handshake. Scary, isn't it?

- Marsh