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

[Martin Rex <[e-mail]>]

Paul Hoffman wrote:
> 
> >
> >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.
> 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. 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.
> 
> 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.
> 
> Does that help?

This will need a lot of big caveats.

Static DH requires DH-certificates, something which is
within [unusual,esoteric,not-implemented] for the
installed base of TLS and CAs.

And if your low-entropy device creates the static DH keypair itself
then you are still screwed, even with this extension.


In the past there have been serious TLS security problems related
to lack-of-entropy for one of the communicating entities.

In 1995 a weakness in the TLS encryption was found in the Netscape
browser based on a lack of entropy in the randomness that was
used for generation of the RSA premaster secret.
http://seclists.org/bugtraq/1995/Sep/62


In 2008, there was an bad change made to Debian's OpenSSL distribution
which totally crippled its cryptographic number generator.
http://www.debian.org/security/2008/dsa-1571


The lack of real entropy creates security problems for (examples):

 - generation of shared secrets (session keys) for
   symmetric cryptography or keyed hashes/MACs
 - generation of asymmetric cryptographic keys (RSA,DSA,DH,EC*,...),
   e.g. for use in credentials, host credentials,
   certificates & certificate requests
 - client-side generation of TLS pre-master secrets for RSA-ciphersuites
 - key exchange with ephemeral Diffie Helman
 - DSA-signatures

so if this extension has any value, it must be tailored to
that specific purpose.  Currently, it leaves _very_ dangerous
impressions with readers and implementors.


-Martin