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

Eric Rescorla <ekr@networkresonance.com> Mon, 08 February 2010 20:41 UTC

Return-Path: <ekr@networkresonance.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502E93A68E8 for <tls@core3.amsl.com>; Mon, 8 Feb 2010 12:41:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.895
X-Spam-Level:
X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OSZxsfu0ksL for <tls@core3.amsl.com>; Mon, 8 Feb 2010 12:41:20 -0800 (PST)
Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id BD0EC3A68DB for <tls@ietf.org>; Mon, 8 Feb 2010 12:41:17 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 01C756E7CFA; Mon, 8 Feb 2010 12:44:25 -0800 (PST)
Date: Mon, 08 Feb 2010 12:44:25 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Dean Anderson <dean@av8.com>
In-Reply-To: <Pine.LNX.4.44.1002081326270.17664-100000@citation2.av8.net>
References: <20100206234400.8834E6E7A4B@kilo.networkresonance.com> <Pine.LNX.4.44.1002081326270.17664-100000@citation2.av8.net>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20100208204426.01C756E7CFA@kilo.networkresonance.com>
Cc: tls@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [TLS] New drafts: adding input to the TLS master secret
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2010 20:41:21 -0000

At Mon, 8 Feb 2010 14:29:12 -0500 (EST),
Dean Anderson wrote:
> On Sat, 6 Feb 2010, Eric Rescorla wrote:
> 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.

With any reasonable PRNG this is not a security concern.

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

This is true only in an information theoretic sense. It is not
correct with any reasonable and reasonably seeded CSPRNG.


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

This is true but irrelevant. If you have enough computing power
you can break all ciphers directly. The amount of computing
power required to reverse the PRNG is comparable if not in
excess of the amount required to break the cipher.


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

Well, this isn't true. In fact, it's a basic design requirement
of CSPRNGs that this not be so (up to the input entropy of the
PRNG). If you have any evidence that the standard PRNGs/PRFs fall
significantly short of this requirement, this would be a result
worthy of publication in a good conference.

-Ekr