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

Martin Rex <> Mon, 08 February 2010 22:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08C7E3A74C8 for <>; Mon, 8 Feb 2010 14:59:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.214
X-Spam-Status: No, score=-10.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b7SHkJWmR7Fi for <>; Mon, 8 Feb 2010 14:59:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 04BCD3A74B9 for <>; Mon, 8 Feb 2010 14:59:00 -0800 (PST)
Received: from by (26) with ESMTP id o18MxtOD001287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 23:59:55 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
To: (Eric Rescorla)
Date: Mon, 8 Feb 2010 23:59:54 +0100 (MET)
In-Reply-To: <> from "Eric Rescorla" at Feb 8, 10 12:44:25 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Subject: Re: [TLS] New drafts: adding input to the TLS master secret
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: Mon, 08 Feb 2010 22:59:02 -0000

Eric Rescorla wrote:
> At Mon, 8 Feb 2010 14:29:12 -0500 (EST),
> Dean Anderson wrote:
> > On Sat, 6 Feb 2010, Eric Rescorla wrote:
> > The primary purpose (unique master_secrets) of these random numbers is
> > unimportant.  If they are not truly random, they expose the
> > pseudo-random sequence generator sequence. This is an unintended (but
> > significant) consequence.
> With any reasonable PRNG this is not a security concern.

You may be looking at the problem from the wrong angle.

If there is not enough entropy to seed your CPRNG, then it is
possible to brute force the entire entropy range and check for matches
with the leaked randomness to know about the "unleaked" randomness
that goes into the client key exchange (or premaster secret for RSA).

If you want to create keying material, then you must have sufficient
entropy in order to prevent attackers from brute-forcing your entire
keyspace -- something which is possible when the implementation
(of the CPRNG an protocols using it) is fully known, and the only
unknown is the entropy that seeds the PRNG.

As soon as you have a strong enough seed of the CPRNG, there is no
more need for this extension.

So the situation is that either you have a problem, then
this extension is not going to help you (actually, if you leak
PRNG state through Hello Randoms or the data in this extension,
it gets _much_ worse), or you do not have a problem, then this
extension becomes completely unnecessary.

A TLS peer that does not have good sources of randomness (which are
necessary to seed a good CPRNG), then that TLS peer should not
leak any of that state by publishing randomness from that CPRNG,
neither through Hello.Random, nor through an extension like the
one proposed.  In those cases, it might be more sensible to use
a simple counter for the Hello.Random and fill in the gmt_time