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

Dean Anderson <> Mon, 26 April 2010 18:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97E6C28C206; Mon, 26 Apr 2010 11:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.613
X-Spam-Status: No, score=-0.613 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4R8g5q4DO9cD; Mon, 26 Apr 2010 11:05:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 131FB28C1F9; Mon, 26 Apr 2010 11:05:16 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (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 <>
To: Marsh Ray <>
In-Reply-To: <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Paul Hoffman <>,,
Subject: Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

Av8 Internet   Prepared to pay a premium for better service?         faster, more reliable, better service
617 256 5494