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

Martin Rex <> Wed, 03 February 2010 02:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1A613A69F3 for <>; Tue, 2 Feb 2010 18:59:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.212
X-Spam-Status: No, score=-10.212 tagged_above=-999 required=5 tests=[AWL=0.038, 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 7KGNbbBnidNe for <>; Tue, 2 Feb 2010 18:59:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DEC473A69B3 for <>; Tue, 2 Feb 2010 18:59:40 -0800 (PST)
Received: from by (26) with ESMTP id o1330HPF004407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Feb 2010 04:00:17 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
To: (Marsh Ray)
Date: Wed, 3 Feb 2010 04:00:16 +0100 (MET)
In-Reply-To: <> from "Marsh Ray" at Feb 2, 10 08:24:45 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
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: Wed, 03 Feb 2010 02:59:42 -0000

Marsh Ray wrote:
> Martin Rex wrote:
> > Marsh Ray wrote:
> >> How big were you planning to make those symmetric keys anyway?
> > 
> > I would prefer to _not_ call anything "key" that is going to
> > travel in the clear.  Personally, I always think of "keys" being
> > secret or even private information.   I would prefer the term
> > "random" or "entropy".
> Sorry if this wasn't clear. I was referring to the actual keys that are
> used for the symmetric algorithm. Negotiating these is one of the main
> goals of the handshake process.
> The point is that it seems like a bit of overkill to require
> more than 448 bits of entropy to generate a key for AES-128.

The useful limit here is probably the size of the MasterSecret (48 bytes)
as Paul indicated.

I share his concern that some TLS peers (those operating in
constrained environments, like small devices, including
handheld devices like PDAs or phones) do not necessarily
have good sources of randomness.

But then, asking them to deplete their pools of randomness
with every SSL handshake and sending that data in the clear
over the network doesn't seem to improve that.

In theory, it would be OK if e.g. such a constrained client
would indicate to the server that it has little randomness
to offer (and itself send an empty extension), and the server
could then take this offer and return additional entropy in
the ServerHello when _NOT_ doing session resumption
(and ignore the extension when doing session resumption),

However, it is not clear to me how this could make up for the lack
of true entropy that goes into the keyexchange performed by the client.