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

Dean Anderson <dean@av8.com> Mon, 26 April 2010 18:05 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 97E6C28C206; Mon, 26 Apr 2010 11:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.613
X-Spam-Level:
X-Spam-Status: No, score=-0.613 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_50=0.001]
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 4R8g5q4DO9cD; Mon, 26 Apr 2010 11:05:20 -0700 (PDT)
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 131FB28C1F9; Mon, 26 Apr 2010 11:05:16 -0700 (PDT)
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 o3QI4xBO006500 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 26 Apr 2010 14:05:02 -0400
Date: Mon, 26 Apr 2010 14:04:59 -0400 (EDT)
From: Dean Anderson <dean@av8.com>
X-X-Sender: dean@citation2.av8.net
To: Marsh Ray <marsh@extendedsubset.com>
In-Reply-To: <4BD5C984.1040001@extendedsubset.com>
Message-ID: <Pine.LNX.4.44.1004261355330.14419-100000@citation2.av8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
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, 26 Apr 2010 18:05:21 -0000

On Mon, 26 Apr 2010, 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.

Except they aren't actaully random, they are pseudo-random.

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

I would think that if attacker could do what you describe below, he
could mount an attack on your pseudo-random number generator using the
(now) exposed output.  But I'm not really sure.

I am pretty confident that every crypto act that isn't founded in theory
and absolutely necessary, actually makes things worse.

The purpose of these bits are to ensure non-collision in practice. The
easiest, simplest, and least-information-leaking means of achieving that
is to use a counter.  More complication and pseudo-random bits doesn't
help achieve that purpose any more effectively, and leaks information
that might be used by the attacker, somehow, someday.  A counter cannot
be used by the attacker.  And if you think it could be, then pick the
initial counter value pseudo-randomly and count up from there (exposing
at most 1 set of bits per reboot)

> I would think that the current 224-256 bits is enough to thwart
> offline attacks. The attacker would need something proportional to
> 2**224 storage to store the results of his precomputation, no?
> 
> Assume attacker can knock off 2**42 using rainbow table techniques (he
> has a 1024 unit cluster of CPUs which can each compute one result
> online every clock at 4GHz). So he needs to store something like
> 2**182 results from his precomputation. Assuming 1 bit per result,
> probably you'd need more. Raw HDDs are the cheapest form of mass
> storage today at $75/TB (10**12 bytes?). Such a system would cost
>              $ 5746858278247083218843801351813700000000000.00
> today. Of course those costs are likely to decline over time.
> 
> Again, this is the cost you impose on the attacker today by simply
> ensuring you use the current protocol as intended.
> 
> > I do believe it's mostly harmless; I am concerned that 2^16 max octets
> > seems like a bit much, possibly a source of DoS attacks.  I believe it's
> > also useless.  As such I'm not opposed to it as an Experimental or even
> > Informational RFC.
> 
> There is a danger with this proposal. In no way do I mean to suggest
> that Paul has any unstated motivations here.
> 
> One aspect of saying that a data area is random is saying that the RFCs
> can impose no restrictions on it. Allowing arbitrary unstructured
> "random" data in the protocol opens the door for private extensions to
> be added by various parties.
> 
> For example, it appears that 4 of the 32 bytes originally specified for
> random data got repurposed for GMT leaving "this is GMT but the clock is
> not required to be right" in the spec.
> 
> Once a few more of these accumulate in the protocol without central
> coordination we end up with incompatibilities that the IETF process can
> no longer prevent.
> 
> - Marsh
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> 

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