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

"Jeffrey A. Williams" <> Mon, 08 February 2010 20:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 867363A7368 for <>; Mon, 8 Feb 2010 12:06:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PAtMScFiZqMc for <>; Mon, 8 Feb 2010 12:06:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BF8043A682A for <>; Mon, 8 Feb 2010 12:06:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327;; b=pssepP0Mmrje8VSwekdUfZzte+I4JSnm6TuIqAPV4V347TMl6MRHtj1z4+oqbyRQ; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [] ( by with esmtpa (Exim 4.67) (envelope-from <>) id 1NeZtK-0000DM-4G; Mon, 08 Feb 2010 15:07:30 -0500
Received: from by with HTTP; Mon, 8 Feb 2010 15:07:29 -0500
Message-ID: <>
Date: Mon, 8 Feb 2010 14:07:29 -0600 (GMT-06:00)
From: "Jeffrey A. Williams" <>
To: Dean Anderson <>, Eric Rescorla <>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606884a341c1a351d059cc8c532c5b32a248a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Cc:, Paul Hoffman <>
Subject: Re: [TLS] New drafts: adding input to the TLS master secret
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams" <>
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: Mon, 08 Feb 2010 20:06:29 -0000

Dean and all,

  Here in your remarks below, I could not agree more.
Well done.  

-----Original Message-----
>From: Dean Anderson <>
>Sent: Feb 8, 2010 1:29 PM
>To: Eric Rescorla <>
>Cc:, Paul Hoffman <>
>Subject: Re: [TLS] New drafts: adding input to the TLS master secret
>On Sat, 6 Feb 2010, Eric Rescorla wrote:
>> At Sat, 6 Feb 2010 17:20:05 -0500 (EST), Dean Anderson wrote:
>> > 
>> > On Wed, 3 Feb 2010, Eric Rescorla wrote:
>> > 
>> > > Moreover, the the purpose of the random values is *not* to add
>> > > extra cryptographic strength, since they're not secret. Rather,
>> > > it's to ensure uniqueness of the handshake master secret even if
>> > > the PMS is repeated. However, the bound here is just the collision
>> > > bound for the random values, which doesn't require anything like
>> > > 224 bits.
>> > > 
>> > > I'm not really against this extension, but I'm not aware of any
>> > > coherent security argument for it.
>> > 
>> > Thinking it over, I have some concerns about the security
>> > implications on the master_secret calculation.  I didn't think about
>> > this until Paul Hoffman wanted to alter and increase the size the
>> > client and server random numbers. I have to dispute that the client
>> > random and server random need not be 'cryptographically random'
>> > instead of known but random values.
>> I'm not sure what you're disputing. Since both values are published,
>> the primary value of having them be cryptographically random is to
>> make them unpredictable in advance to the attacker. However, I am
>> unaware of any security analysis that relies on this property.
>"cryptographically random" was a poor term. It confuses 'cryptographic
>PRNG' with 'truly random' or zero-information numbers. I mean the
>I'm disputing the assertion that these random numbers don't need to be
>truly random.  To recast it as a positive assertion: I'm asserting these
>randoms have to be either truly random or truly non-cryptographically
>random; They cannot be part of a pseudo-random sequence. Particularly:  
>they cannot be from the PRNG that the pre_master_secret comes from.
>The primary purpose (unique master_secrets) of these random numbers is
>unimportant.  If they are not truly random, they expose the
>pseudo-random sequence generator sequence. This is an unintended (but
>significant) consequence.
>> >> And I have a concern that they are not secret.  The only
>> > entropy in the calculation is the pre_master_secret.
>> >
>> > First, I am concerned that the entropy of the pre_master_secret is
>> > reduced by presence of the revealed random number.  In the absence
>> > of a perfect random number generator, the pre_master_secret and the
>> > random number are not independent.
>> Well, this isn't true for the server half of the static RSA cipher
>> suites, since the server doesn't contribute to the PMS at all.
>True, the server random doesn't expose the client's pre_master_secret in
>that _particular_ calculation.  But the server IS still exposing its
>(possibly dependent) random numbers. If you collect enough of these
>through snooping, you can predict its pre_master_secret for connections
>orginating from that machine. Same goes for the client machine. Server
>machines tend to be both client and server at different times.
>> In any case, this is an argument for *not* generating the Random
>> values with a cryptographic PRNG since then you would not be leaking
>> information about the PRNG state in the random values.
>Yes. That's my point. By 'cryptographic PRNG' you mean a PRNG that is
>hard to predict. But if you get enough of its sequence and have enough
>compute power, all PRNG's are predictable.
>> > I think the rule of thumb is never to give out random numbers to
>> > potential attackers if your random numbers aren't perfectly random,
>> > and it's hard in practice to have perfectly random numbers. So this
>> > seems like a crack in security in many implementations that could
>> > potentially be exploited.
>> I am not aware of any such rule of thumb. In fact, this design is a
>> fairly standard feature of cryptographic protocols.
>I'll see if I can find a better reference.  I think the cryptographic
>fact I'm looking for is that a pseudo-random sequence is compromised by
>having part of the sequence known. Having more of the sequence known
>makes it even easier to compromise.
>> This isn't how PRFs like the TLS PRF work. Adding new known data does
>> not dilute the existing entropy.
>For SHA-256, I agree--or at least I can't dispute that at this time*.  
>But recall that extensions can specify different PRFs. Perhaps it should
>be documented somewhere that adding new known data must not dilute the
>existing entropy.
>[*Actually, I suspect it isn't true. For the algorithm to be reversible,
>certain other things have to be true.  The object of the hash function
>is to be irreversible, but they all seem never to really get that
>property, just the property of being hard to reverse, which doesn't
>affect the properties that must be true if they are reversible. If you
>assume they are reversible, and add more known data to the limited
>output (which began at a maximum entropy, then entropy of the output
>must be reduced. To put it another way: If you start with a lump of iron
>(at maximum entropy), and beat it into an iron pot of the same mass
>(known input), entropy is reduced. Knowing the exact sequence to get the
>pot from the rock reveals information about the rock. But this is no
>		--Dean
>Av8 Internet   Prepared to pay a premium for better service?
>         faster, more reliable, better service
>617 256 5494
>TLS mailing list


Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 294k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
Phone: 214-244-4827