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

Eric Rescorla <ekr@networkresonance.com> Tue, 09 February 2010 03:23 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 AE4483A726D for <tls@core3.amsl.com>; Mon, 8 Feb 2010 19:23:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.018
X-Spam-Level:
X-Spam-Status: No, score=0.018 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, 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 1TCtOs5f6CVb for <tls@core3.amsl.com>; Mon, 8 Feb 2010 19:23:51 -0800 (PST)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id C5B273A7258 for <tls@ietf.org>; Mon, 8 Feb 2010 19:23:51 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 476306E7D80; Mon, 8 Feb 2010 19:27:03 -0800 (PST)
Date: Mon, 08 Feb 2010 19:27:01 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: mrex@sap.com
In-Reply-To: <201002082259.o18MxsB6017864@fs4113.wdf.sap.corp>
References: <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=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Message-Id: <20100209032703.476306E7D80@kilo.networkresonance.com>
Cc: paul.hoffman@vpnc.org, tls@ietf.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: Tue, 09 Feb 2010 03:23:52 -0000

At Mon, 8 Feb 2010 23:59:54 +0100 (MET),
Martin Rex wrote:
> 
> 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.
> 
> You may be looking at the problem from the wrong angle.
> 
> If there is not enough entropy to seed your CPRNG, then it is
> possible to brute force the entire entropy range and check for matches
> with the leaked randomness to know about the "unleaked" randomness
> that goes into the client key exchange (or premaster secret for RSA).

Yes, I'm aware of this fact. In fact, see [YRS+09] for a worked example.


> A TLS peer that does not have good sources of randomness (which are
> necessary to seed a good CPRNG), then that TLS peer should not
> leak any of that state by publishing randomness from that CPRNG,
> neither through Hello.Random, nor through an extension like the
> one proposed.  In those cases, it might be more sensible to use
> a simple counter for the Hello.Random and fill in the gmt_time
> correctly.


It's not clear to me that avoiding leakage of any PRNG output helps
that much, since an attacker who knows the potential outputs of the
PRNG can simply do trial decryption to see if the projected outputs
produce correct decryptions. The reason it helps in the example above
is that you need to track the evolution of the PRNG through multiple
requests. However, this seems like a fairly unusual case. It 
would not, for instance, likely apply to clients, which only
maintain a small number of PRNG contexts.

In general, if you have an acceptable amount of entropy you
don't need to worry about leaking PRNG output. If you don't
you really don't have any business doing TLS.

-Ekr


[YRS+09] S. Yilek, E. Rescorla, H. Shacham, B. Enright, and S. Savage
"When Private Keys are Public: Results from the 2008 Debian OpenSSL
Vulnerability", In Proceedings of IMC 2009, pages 15?27. ACM Press, 
Nov. 2009.