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

Martin Rex <> Thu, 22 April 2010 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E6773A6B70; Thu, 22 Apr 2010 08:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.237
X-Spam-Status: No, score=-8.237 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TlDJhynSKCRr; Thu, 22 Apr 2010 08:52:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D99443A6BB2; Thu, 22 Apr 2010 08:52:20 -0700 (PDT)
Received: from by (26) with ESMTP id o3MFq9p0008106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2010 17:52:09 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (Paul Hoffman)
Date: Thu, 22 Apr 2010 17:52:08 +0200 (MEST)
In-Reply-To: <p06240803c7f60d8cde2c@[]> from "Paul Hoffman" at Apr 22, 10 07:29:46 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Subject: Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Apr 2010 15:52:32 -0000

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.

In 2008, there was an bad change made to Debian's OpenSSL distribution
which totally crippled its cryptographic number generator.

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.