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 3C44C28C12C for <tls@core3.amsl.com>; Mon, 8 Feb 2010 12:41:56 -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 wgM9RSiYbFj0 for <tls@core3.amsl.com>; Mon, 8 Feb 2010 12:41:55 -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 77B3128C116 for <tls@ietf.org>; Mon, 8 Feb 2010 12:41:55 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 3BE986E7CFB; Mon, 8 Feb 2010 12:45:04 -0800 (PST)
Date: Mon, 08 Feb 2010 12:45:04 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Dean Anderson <dean@av8.com>
In-Reply-To: <20100208204426.01C756E7CFA@kilo.networkresonance.com>
References: <20100206234400.8834E6E7A4B@kilo.networkresonance.com> <Pine.LNX.4.44.1002081326270.17664-100000@citation2.av8.net> <20100208204426.01C756E7CFA@kilo.networkresonance.com>
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: <20100208204504.3BE986E7CFB@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:56 -0000

At Mon, 08 Feb 2010 12:44:25 -0800,
Eric Rescorla wrote:
> 
> 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.

And by correct I mean "it's not computationally feasible".

-Ekr