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

"Brian Smith" <> Tue, 02 February 2010 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 017DD3A6B72 for <>; Tue, 2 Feb 2010 13:03:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YZbqkIqfVKGb for <>; Tue, 2 Feb 2010 13:03:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E93CB3A69A1 for <>; Tue, 2 Feb 2010 13:03:08 -0800 (PST)
Received: from T60 (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 76C23509DD; Tue, 2 Feb 2010 16:03:41 -0500 (EST)
From: "Brian Smith" <>
To: "'Paul Hoffman'" <>
References: <p0624089bc78922bdaddd@[]> <> <p06240813c78e116da3f6@[]> <001001caa442$beefbde0$3ccf39a0$@org> <p06240829c78e37e5a850@[]>
In-Reply-To: <p06240829c78e37e5a850@[]>
Date: Tue, 2 Feb 2010 15:03:41 -0600
Message-ID: <001101caa44b$35f6f540$a1e4dfc0$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: en-us
Thread-Index: AcqkRQjAtL7ljGpeSQCvkxWcS991UwAAVV6w
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:03:10 -0000

Paul Hoffman wrote:
> 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.

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

I misunderstood how the extensions work. Thanks for the clarification.

> At 2:03 PM -0600 2/2/10, Brian Smith wrote:
> >(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.

OK, I shouldn't have said "channel binding," but all of the concerns still
stand, AFAICT. If the additional inputs are random data then it may be OK to
send them in the clear. However, other kinds of additional inputs like user
identities would be better off protected. And, it is better not to increase
the size/processing of the hello messages required before each party gets to
see the other's certificate. If these additional inputs appear in hello
messages then the only way to protect them is with the handshake/renegotiate
anti-pattern, which makes connection latency even worse by adding more round

Any  extensions that contain non-trivial amounts of data and/or possibly
sensitive information should be transmitted after change_cipher_spec
messages--not in hello messages--whenever practical. When a hello extension
does contain non-trivial amounts of information or sensitive information,
then the security considerations section of its specification should explain
why the extension cannot be moved to after the change_cipher_spec messages. 

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