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

Stefan Santesson <> Sat, 30 January 2010 00:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EFB63A682C for <>; Fri, 29 Jan 2010 16:35:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pT9g1SNyibUH for <>; Fri, 29 Jan 2010 16:35:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 751943A635F for <>; Fri, 29 Jan 2010 16:35:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1FE3334683D for <>; Sat, 30 Jan 2010 01:35:42 +0100 (CET)
Received: (qmail 54621 invoked from network); 30 Jan 2010 00:35:32 -0000
Received: from (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <>; 30 Jan 2010 00:35:32 -0000
User-Agent: Microsoft-Entourage/
Date: Sat, 30 Jan 2010 01:35:31 +0100
From: Stefan Santesson <>
To: Paul Hoffman <>, <>
Message-ID: <>
Thread-Topic: [TLS] New drafts: adding input to the TLS master secret
Thread-Index: AcqhRCCVpeRCS7IhQ0CHq1UvNZovaw==
In-Reply-To: <p0624089bc78922bdaddd@[]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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: Sat, 30 Jan 2010 00:35:12 -0000


I have a few questions:

1)  Could/Should the draft say anything more about the benefits?

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?

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)

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

Which extension will provide ClientHello.additional_ms_input_1 and
ClientHello.additional_ms_input_2. How can you sort this out unless each
extension explicitly define its input order in relation to other similar
extensions or by creating an IANA registry where input's and their order are


On 10-01-30 12:42 AM, "Paul Hoffman" <> wrote:

> Greetings again. I have submitted two drafts that are probably of interest to
> some people in the TLS WG. I intend to submit them as individual submissions,
> not through the WG, but getting input from the WG before I do so would be
> great.
> The first document changes the TLS/DTLS master secret calculation when there
> are particular kinds of extensions present. Of course, it does not change the
> calculation when those extensions are not present, and there are no extensions
> yet that would kick in the change.
> The second document is an extension that is similar to the one that Ekr
> proposed over a year ago. It allows one or both parties to add more random
> input to the master secret calculation. This is desired by some organizations
> who want to match the guaranteed amount of randomness in the master secret
> calculation with the strength of the encryption and authentication functions.
> Both documents are (purposely) short and hopefully easy to read. If you have
> any comments, send them to me or, if you think they pertain to the WG, maybe
> send them here. Again, these are not meant to be WG work items; I doubt that
> the effort to recharter and so on would be worth the value.
> --Paul Hoffman
> Title  : Additional Master Secret Inputs for TLS
> Author(s) : P. Hoffman
> Filename : draft-hoffman-tls-master-secret-input-00.txt
> Pages  : 4
> Date  : 2010-1-29
>    This document describes a mechanism for using additional master
>    secret inputs with Transport Layer Security (TLS) and Datagram TLS
>    (DTLS).
> A URL for this Internet-Draft is:
> xt
> Title  : Additional Random Extension to TLS
> Author(s) : P. Hoffman
> Filename : draft-hoffman-tls-additional-random-ext-00.txt
> Pages  : 3
> Date  : 2010-1-29
>    This document specifies a TLS/DTLS extension that uses the additional
>    master secret inputs to achieve useful security properties.
> A URL for this Internet-Draft is:
> .txt
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> TLS mailing list