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

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 02 February 2010 20: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 1423A3A6B53 for <tls@core3.amsl.com>; Tue, 2 Feb 2010 12:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.051
X-Spam-Level:
X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 yBFX8yrq5p4d for <tls@core3.amsl.com>; Tue, 2 Feb 2010 12:19:03 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 98D1F28C0E1 for <tls@ietf.org>; Tue, 2 Feb 2010 12:18:54 -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 o12KJT7T070934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 13:19:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240829c78e37e5a850@[75.101.18.87]>
In-Reply-To: <001001caa442$beefbde0$3ccf39a0$@org>
References: <p0624089bc78922bdaddd@[10.20.30.158]> <87fx5jk8vp.fsf@mocca.josefsson.org> <p06240813c78e116da3f6@[75.101.18.87]> <001001caa442$beefbde0$3ccf39a0$@org>
Date: Tue, 2 Feb 2010 12:19:28 -0800
To: "Brian Smith" <brian@briansmith.org>
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: Tue, 02 Feb 2010 20:19:04 -0000

At 2:03 PM -0600 2/2/10, Brian Smith wrote:
> (a) Why does the intro say that extensions want to mix "particular data"
>into the calculation of the master secret? I think "additional random data"
>would be clearer.

That phrase appears in the introduction to draft-hoffman-tls-master-secret-input, *not* in draft-hoffman-tls-additional-random-ext. The former is the description of how to make extensions that mix particular data into the master secret; the latter is the definition of one such extension.

>(b) Why does there need to be more than one kind of additional input type?
>It seems like the sending side could just concatenate all the additional
>input into a single "additional_input" extension before it sends it. I think
>it's because this foundational work for channel binding mechanism. In that
>case, the IETF should treat the this mechanism and the channel binding
>mechanism as a single item to be accepted/rejected together--if channel
>binding gets rejected then there's no need (AFAICT) for multiple
>additional_input extensions.

There needs to be more than one additional input type because different parties might want to use different extensions. For example, if someone comes up with an extension for mixing in user identities (I'm using this as an example, not a suggestion), they might not want to mix in additional random. Thus, the extensions should remain separate.

And, to be clear, this is not "foundational work for channel binding mechanism". It is orthogonal to the work that has been proposed in that area. Note that the term "channel binding" does not appear in the drafts. 

>(c) Besides channel binding, an implementation might support this to help
>ensure a certain level of entropy was used for the pseudorandom inputs to
>the PRF for calculating the master secret. Why not include the definition of
>this extension in the same document, instead of requiring a separate
>document to define it?

Pasi Eronen, the AD, preferred the two proposals be split into two separate documents.

>(d) Wouldn't it be better to use the normal master_secret calculations to
>establish a secure channel, and then send the parameters for modifying the
>master secret over that secure connection? This would reduce the amount of
>data sent in the clear, so that an outside observer could not tell if/which
>channels are bound together. And it would reduce DoS on the entropy source
>of the PRNGs of each party, by allowing each party to authenticate the other
>before processing the extension. Finally, it would keep ClientHello messages
>small, which is important for improving latency.

Again, this presumes that the purpose is channel binding, and it is not.

--Paul Hoffman, Director
--VPN Consortium