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

Dean Anderson <dean@av8.com> Sat, 06 February 2010 22:19 UTC

Return-Path: <dean@av8.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 5BFFE3A7117 for <tls@core3.amsl.com>; Sat, 6 Feb 2010 14:19:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.084
X-Spam-Level:
X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599]
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 sevxdFVntfQK for <tls@core3.amsl.com>; Sat, 6 Feb 2010 14:19:18 -0800 (PST)
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id DEBD63A6F8A for <tls@ietf.org>; Sat, 6 Feb 2010 14:19:17 -0800 (PST)
Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id o16MK6kT025202 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 6 Feb 2010 17:20:09 -0500
Date: Sat, 6 Feb 2010 17:20:05 -0500 (EST)
From: Dean Anderson <dean@av8.com>
X-X-Sender: dean@citation2.av8.net
To: Eric Rescorla <ekr@networkresonance.com>
In-Reply-To: <20100204050608.89EFF6E70AD@kilo.networkresonance.com>
Message-ID: <Pine.LNX.4.44.1002061608290.7192-100000@citation2.av8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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 22:19:19 -0000

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

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.

Paul Hoffman's draft is only outside the charter because of the
admonition "In the preparation of TLS 1.2, the WG will attempt to avoid
gratuitous changes to TLS 1.1.". However, the master_secret calculation
and changes to it are in scope for the TLS working group--it is not the
case that changes are out of scope, but that the Working Group is under
instructions not to make "gratuitous changes". It seems to me that
Paul's draft circumvents this instruction.

So I think the WG should look into the calculation of the master_secret
for security weaknesses. If there is indeed a security issue, fixing
that would not be a "gratuitous change".

		--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494