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

Paul Hoffman <> Tue, 02 February 2010 17:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE49128C0D7 for <>; Tue, 2 Feb 2010 09:37:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.084
X-Spam-Status: No, score=-5.084 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, SARE_RAND_1=2]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nK7OsRfWGTfa for <>; Tue, 2 Feb 2010 09:37:36 -0800 (PST)
Received: from (Balder-227.Proper.COM []) by (Postfix) with ESMTP id 2E31628C0CE for <>; Tue, 2 Feb 2010 09:37:36 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.2/8.14.2) with ESMTP id o12HcCdT061028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 10:38:14 -0700 (MST) (envelope-from
Mime-Version: 1.0
Message-Id: <p06240813c78e116da3f6@[]>
In-Reply-To: <>
References: <p0624089bc78922bdaddd@[]> <>
Date: Tue, 2 Feb 2010 09:38:11 -0800
To: Simon Josefsson <>
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 17:37:37 -0000

At 3:30 PM +0100 2/2/10, Simon Josefsson wrote:
>I have read these two documents and believe they are generally fine.  As
>far as I can tell, they are not backwards compatible with earlier


>But that is not important.

I believe that is the case as well. The changes only are needed if both parties agree to use a TLS/DTLS extension that need the changes, and that negotiation is completely explicit. If an implementation doesn't support any such extension, there is no reason for it to support the changes either.

>There is one thing in draft-hoffman-tls-additional-random-ext-00.txt
>that bothers me: There is no requirement that additional random data is
>generated using cryptographic principles.  This means the extension can
>be used as a general-purpose extension mechanism to exchange data that
>has meaning to, for example, some middle-ware that sits between the
>client and server.
>Is this the intention?  I'm assuming no, and that the
>additional_random_value actually are intended to be, well, just an
>additional random value.

Correct. That's why the document says:
   The recipient of an additional_random extension MUST NOT try to parse
   the additional_random_value.

>Therefor, I would suggest that a new requirement is added:
>   The client and server MUST generate the additional_random_value data
>   using a secure random number generator.  [RANDOM] provides guidance
>   on the generation of random values.
>   [RANDOM]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
>              "Randomness Requirements for Security", BCP 106, RFC 4086,
>              June 2005.

This is a great addition, thanks. It will be in the -01.

--Paul Hoffman, Director
--VPN Consortium