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

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 30 January 2010 01:10 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 8EE5A3A635F for <tls@core3.amsl.com>; Fri, 29 Jan 2010 17:10:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.082
X-Spam-Level:
X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 yjuzfSgu6SFL for <tls@core3.amsl.com>; Fri, 29 Jan 2010 17:10:02 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 72F053A68DF for <tls@ietf.org>; Fri, 29 Jan 2010 17:10:02 -0800 (PST)
Received: from [10.20.30.158] (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 o0U1AKKV026944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jan 2010 18:10:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0624089cc7893479d5d1@[10.20.30.158]>
In-Reply-To: <C7893D63.7FE7%stefan@aaa-sec.com>
References: <C7893D63.7FE7%stefan@aaa-sec.com>
Date: Fri, 29 Jan 2010 17:10:18 -0800
To: Stefan Santesson <stefan@aaa-sec.com>, <tls@ietf.org>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
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: Sat, 30 Jan 2010 01:10:04 -0000

At 1:35 AM +0100 1/30/10, Stefan Santesson wrote:
>1)  Could/Should the draft say anything more about the benefits?

Not really; I put what I knew into the doc.

>The draft states the undeniable fact that "This mixing creates a
>cryptographic binding of the added material directly into the secret that is
>used to protect the TLS session.  For example, some systems want to be sure
>that there is sufficient randomness in the TLS master_secret"
>
>But is this solution provided because the PRF, unless amended with
>additional entropy, could cause security issues that motivates this change?

The first sentence (mixing) is, as you say, undeniable. Different people want different items cryptographically mixed into the secret. For instance, some people really want the parties' identities mixed in. (Note that I'm not proposing to do that, just saying that some folks want it.)

The second sentence (random) is the motivation for the extension. A PRF which turns out to be weaker than expected might have that weakness shored up by stuffing more random in the master_secret. To date, no PRF weaknesses have ever been made worse by adding random inputs.

>2) What is the added value of defining the amended master secret calculation
>in absence of any extension that provide data to the calculation.
>
>Once such extension is defined, would it not have to more or less duplicate
>the definition provided in this draft? (e.g. see question 3)

There is no value to amending the calculation unless there is at least one extension that will use it. However, do not assume that the only possible valuable extension is for adding randomness; there are others that other folks might want in the future.

>3) How do you decide the order of input from multiple extensions?

That's covered in draft-hoffman-tls-master-secret-input:

   For the calculation of the master secret, the
   extensions MUST be sorted by extension type order.  Note that RFC
   5246 specifies that there can only be one extension per type, and the
   extensions can appear in mixed order.

--Paul Hoffman, Director
--VPN Consortium