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

Paul Hoffman <> Tue, 02 February 2010 21:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 082DD28C10C for <>; Tue, 2 Feb 2010 13:55:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.05
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OzdUKo4BfcWK for <>; Tue, 2 Feb 2010 13:55:41 -0800 (PST)
Received: from (Balder-227.Proper.COM []) by (Postfix) with ESMTP id 5227D28C10A for <>; Tue, 2 Feb 2010 13:55:41 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.2/8.14.2) with ESMTP id o12LuH3G076621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 14:56:18 -0700 (MST) (envelope-from
Mime-Version: 1.0
Message-Id: <p06240831c78e4f0e15ee@[]>
In-Reply-To: <001101caa44b$35f6f540$a1e4dfc0$@org>
References: <p0624089bc78922bdaddd@[]> <> <p06240813c78e116da3f6@[]> <001001caa442$beefbde0$3ccf39a0$@org> <p06240829c78e37e5a850@[]> <001101caa44b$35f6f540$a1e4dfc0$@org>
Date: Tue, 2 Feb 2010 13:56:15 -0800
To: "Brian Smith" <>
From: Paul Hoffman <>
Content-Type: text/plain; charset="us-ascii"
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: Tue, 02 Feb 2010 21:55:42 -0000

At 3:03 PM -0600 2/2/10, Brian Smith wrote:
>Anyway, please disregard my mention of channel binding. What I really meant
>is that it's hard to understand and evaluate
>draft-hoffman-tls-master-secret-input without seeing the definitions of the
>other kinds of additional input--in particular, whether or not those kinds
>of additional input are better put before or after the first
>change_cipher_spec message (consequently, before or after an initial master
>secret is calculated).

Nothing in draft-hoffman-tls-master-secret-input prevents someone from writing an extension that uses data exchange after the change_cipher_spec message. Folks have been welcome to write such extensions before now, and will continue to be welcome to after this. 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.

--Paul Hoffman, Director
--VPN Consortium