Re: [TLS] New drafts: adding input to the TLS master secret
Eric Rescorla <ekr@networkresonance.com> Sat, 06 February 2010 23: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 C5B873A7121 for <tls@core3.amsl.com>; Sat, 6 Feb 2010 15:41:11 -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 ZgD3UNQ8YAnL for <tls@core3.amsl.com>; Sat, 6 Feb 2010 15:41:10 -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 CEF4E3A70CC for <tls@ietf.org>; Sat, 6 Feb 2010 15:41:10 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 8834E6E7A4B; Sat, 6 Feb 2010 15:44:00 -0800 (PST)
Date: Sat, 06 Feb 2010 15:43:59 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Dean Anderson <dean@av8.com>
In-Reply-To: <Pine.LNX.4.44.1002061608290.7192-100000@citation2.av8.net>
References: <20100204050608.89EFF6E70AD@kilo.networkresonance.com> <Pine.LNX.4.44.1002061608290.7192-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: <20100206234400.8834E6E7A4B@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: Sat, 06 Feb 2010 23:41:11 -0000
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. >> 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. 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. > 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. > Second, if the pre_master_secret is the only real secret, while the > client random and server random are known, then more of the input to the > PRF is known, and thus the output of the PRF must also be more > predictable (at least due to less entropy in the dependent > pre_master_secret). Changing the client random and/or server random to > be even larger known values seems (intuitively anyway--I'm not sure this > is the case) to impose an even more negative impact on the > predictabilitiy of the PRF output. It seems to me like that might be a > security vulnerability, too. It has been reported that AES may be > significantly weaker than expected when some bits of the key are known. This isn't how PRFs like the TLS PRF work. Adding new known data does not dilute the existing entropy. -Ekr
- Re: [TLS] New drafts: adding input to the TLS mas… Stefan Santesson
- [TLS] New drafts: adding input to the TLS master … Paul Hoffman
- Re: [TLS] New drafts: adding input to the TLS mas… Paul Hoffman
- Re: [TLS] New drafts: adding input to the TLS mas… Dean Anderson
- Re: [TLS] New drafts: adding input to the TLS mas… Paul Hoffman
- Re: [TLS] New drafts: adding input to the TLS mas… Simon Josefsson
- Re: [TLS] New drafts: adding input to the TLS mas… Paul Hoffman
- Re: [TLS] New drafts: adding input to the TLS mas… Simon Josefsson
- Re: [TLS] New drafts: adding input to the TLS mas… Brian Smith
- Re: [TLS] New drafts: adding input to the TLS mas… Paul Hoffman
- Re: [TLS] New drafts: adding input to the TLS mas… Brian Smith
- Re: [TLS] New drafts: adding input to the TLS mas… Martin Rex
- Re: [TLS] New drafts: adding input to the TLS mas… Paul Hoffman
- Re: [TLS] New drafts: adding input to the TLS mas… Marsh Ray
- Re: [TLS] New drafts: adding input to the TLS mas… Martin Rex
- Re: [TLS] New drafts: adding input to the TLS mas… Paul Hoffman
- Re: [TLS] New drafts: adding input to the TLS mas… Marsh Ray
- Re: [TLS] New drafts: adding input to the TLS mas… Martin Rex
- Re: [TLS] New drafts: adding input to the TLS mas… Paul Hoffman
- Re: [TLS] New drafts: adding input to the TLS mas… Marsh Ray
- Re: [TLS] New drafts: adding input to the TLS mas… Paul Hoffman
- Re: [TLS] New drafts: adding input to the TLS mas… Bill Frantz
- Re: [TLS] New drafts: adding input to the TLS mas… Marsh Ray
- Re: [TLS] New drafts: adding input to the TLS mas… Paul Hoffman
- Re: [TLS] New drafts: adding input to the TLS mas… Paul Hoffman
- Re: [TLS] New drafts: adding input to the TLS mas… Marsh Ray
- Re: [TLS] New drafts: adding input to the TLS mas… Paul Hoffman
- Re: [TLS] New drafts: adding input to the TLS mas… Eric Rescorla
- Re: [TLS] New drafts: adding input to the TLS mas… Dean Anderson
- Re: [TLS] New drafts: adding input to the TLS mas… Eric Rescorla
- Re: [TLS] New drafts: adding input to the TLS mas… Dean Anderson
- Re: [TLS] New drafts: adding input to the TLS mas… Jeffrey A. Williams
- Re: [TLS] New drafts: adding input to the TLS mas… Eric Rescorla
- Re: [TLS] New drafts: adding input to the TLS mas… Eric Rescorla
- Re: [TLS] New drafts: adding input to the TLS mas… Martin Rex
- Re: [TLS] New drafts: adding input to the TLS mas… Dean Anderson
- Re: [TLS] New drafts: adding input to the TLS mas… Dean Anderson
- Re: [TLS] New drafts: adding input to the TLS mas… Marsh Ray
- Re: [TLS] New drafts: adding input to the TLS mas… Eric Rescorla
- Re: [TLS] New drafts: adding input to the TLS mas… Eric Rescorla
- Re: [TLS] New drafts: adding input to the TLS mas… Eric Rescorla
- Re: [TLS] New drafts: adding input to the TLS mas… Martin Rex
- Re: [TLS] New drafts: adding input to the TLS mas… Eric Rescorla
- Re: [TLS] New drafts: adding input to the TLS mas… Marsh Ray
- Re: [TLS] New drafts: adding input to the TLS mas… Dean Anderson
- Re: [TLS] New drafts: adding input to the TLS mas… Marsh Ray
- Re: [TLS] New drafts: adding input to the TLS mas… Dean Anderson
- Re: [TLS] New drafts: adding input to the TLS mas… Martin Rex
- Re: [TLS] New drafts: adding input to the TLS mas… James Manger