Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext

Martin Rex <mrex@sap.com> Mon, 26 April 2010 17:50 UTC

Return-Path: <mrex@sap.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 99A6828C1DC; Mon, 26 Apr 2010 10:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.193
X-Spam-Level:
X-Spam-Status: No, score=-8.193 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 T7qNxCeTrzHH; Mon, 26 Apr 2010 10:50:34 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id BDA2F28C1DA; Mon, 26 Apr 2010 10:50:27 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o3QHoBsa025767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Apr 2010 19:50:11 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201004261750.o3QHo9qE003004@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com (Marsh Ray)
Date: Mon, 26 Apr 2010 19:50:09 +0200 (MEST)
In-Reply-To: <4BD5C984.1040001@extendedsubset.com> from "Marsh Ray" at Apr 26, 10 12:12:36 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: paul.hoffman@vpnc.org, ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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, 26 Apr 2010 17:50:35 -0000

Marsh Ray wrote:
> 
> On 4/23/2010 12:12 PM, Nicolas Williams wrote:
> > 
> > Irrelevant: if the random octets being sent don't add entropy (because
> > they are sent in cleartext) then this extension is completely orthogonal
> > to PRNG failures.
> 
> Even though they are sent in-the-clear, the random data do serve the
> same useful purpose as the existing [cs]_random data.
> 
> (Mathemeticians and professional cryptographers should probably avert
> their eyes from the fast-and-loose reasoning which follows.)
> 
> Because they are unpredictable they make offline precomputation harder.
> I think of it as adding entropy into offline computation, without adding
> any to the online computation.


This data does add the exact same workfactor to the rightful user
than it adds to each of the attackers brute force attempts.

When you look at the two things that are done to raise the
work factor on password based encryption: random salts and
iteration count, then this data is equivalent to the
random salt.

The advantage of the random salt over the iteration count is,
that it thwarts the creation of "rainbow tables", i.e. attacks
aided by precomputed data.  The disadvantage is that it requires
persisting or exchanging more data (the random salt).


-Martin