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

Marsh Ray <> Wed, 03 February 2010 01:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B560D3A67B2 for <>; Tue, 2 Feb 2010 17:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9uC-BegcUoZO for <>; Tue, 2 Feb 2010 17:50:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E9D6828C13F for <>; Tue, 2 Feb 2010 17:50:03 -0800 (PST)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1NcUOB-000JAq-Pb; Wed, 03 Feb 2010 01:50:43 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 7894A64F2; Wed, 3 Feb 2010 01:50:42 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1/8GpRkC9iNLLGCLR2F3vEkBwbmXTgb2Hc=
Message-ID: <>
Date: Tue, 02 Feb 2010 19:50:42 -0600
From: Marsh Ray <>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
To: Paul Hoffman <>
References: <p0624089bc78922bdaddd@[]> <> <p06240813c78e116da3f6@[]> <001001caa442$beefbde0$3ccf39a0$@org> <p06240829c78e37e5a850@[]> <001101caa44b$35f6f540$a1e4dfc0$@org> <p06240831c78e4f0e15ee@[]>
In-Reply-To: <p06240831c78e4f0e15ee@[]>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 01:50:04 -0000

Paul Hoffman wrote:
> This proposed protocol change is only relevant to scenarios where
> there is a cryptographic reason to mix inherently non-sensitive data
> passed before the change_cipher_spec message into the master secret.

I don't get it. (Sorry I am a little dense sometimes)

You said the data is "not sensitive" and it is sent in plain text. So an
attacker has it as soon as the endpoints do.

What does this accomplish over just hashing your extra data into the 28
byte random field? (which would not require a new protocol structure)

224 bits of from each endpoint ... is 448 bits really not enough entropy
somehow? 448 bits ought to be enough for anybody :-)

It looks to me (but IANAC) like the PRF maxes out at 672 bits of entropy
doing key block expansion (master_secret[48]*8 + 128md5 + 160sha), so
you can only effectively add 224 bits (only 50% more) from any source.

How big were you planning to make those symmetric keys anyway?

- Marsh