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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 03 February 2010 02:19 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D76BF3A687C for <tls@core3.amsl.com>; Tue, 2 Feb 2010 18:19:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.05
X-Spam-Level:
X-Spam-Status: No, score=-6.05 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsq0l931zGmI for <tls@core3.amsl.com>; Tue, 2 Feb 2010 18:19:38 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 755663A6BAB for <tls@ietf.org>; Tue, 2 Feb 2010 18:19:38 -0800 (PST)
Received: from [75.101.18.87] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o132KFL6091211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 19:20:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0624083bc78e8c1563cc@[75.101.18.87]>
In-Reply-To: <4B68D672.2060609@extendedsubset.com>
References: <p0624089bc78922bdaddd@[10.20.30.158]> <87fx5jk8vp.fsf@mocca.josefsson.org> <p06240813c78e116da3f6@[75.101.18.87]> <001001caa442$beefbde0$3ccf39a0$@org> <p06240829c78e37e5a850@[75.101.18.87]> <001101caa44b$35f6f540$a1e4dfc0$@org> <p06240831c78e4f0e15ee@[75.101.18.87]> <4B68D672.2060609@extendedsubset.com>
Date: Tue, 2 Feb 2010 18:20:13 -0800
To: Marsh Ray <marsh@extendedsubset.com>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: tls@ietf.org
Subject: Re: [TLS] New drafts: adding input to the TLS master secret
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2010 02:19:40 -0000

At 7:50 PM -0600 2/2/10, Marsh Ray wrote:
>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.

Of course.

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

You get more random bits mixed into the master secret. This gives you better cryptographic properties if your PRF has an output that is larger than 28 bytes, such as SHA-256 and SHA-384 (but not SHA-1, of course).

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

That's one opinion, maybe that of the people who wrote the current key mechanism. There is also an explicit assumption there that both users have good sources of randomness; if one doesn't, then it sure looks more like 224 bits total, which is not good enough for some people. This extension allows each party to introduce enough randomness to the master secret to overcome a complete failure of their peer's RNG.

>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.

Adding 224 bits to your earlier 224 bits should, indeed, be enough for most people's security needs.

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

48 bytes, as shown in the document.

--Paul Hoffman, Director
--VPN Consortium