IETF Logo Mail Archive

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

Marsh Ray <marsh@extendedsubset.com> Mon, 26 April 2010 17:14 UTC

Return-Path: <marsh@extendedsubset.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 7D1A83A6837; Mon, 26 Apr 2010 10:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 N4He0HoGAihk; Mon, 26 Apr 2010 10:14:23 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 31CBC3A6967; Mon, 26 Apr 2010 10:12:52 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1O6RrL-000OZ9-U1; Mon, 26 Apr 2010 17:12:40 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8595F60B6; Mon, 26 Apr 2010 17:12:38 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/xQubMg4IjYWIfRTeG4CWiBbT3dAytiJM=
Message-ID: <4BD5C984.1040001@extendedsubset.com>
Date: Mon, 26 Apr 2010 12:12:36 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Nicolas Williams <Nicolas.Williams@oracle.com>
References: <201004212205.o3LM5pwQ019241@fs4113.wdf.sap.corp> <p06240887c7f52b14f905@[10.20.30.158]> <87fx2oxvua.fsf@mocca.josefsson.org> <p06240801c7f75b4444b0@[10.20.30.249]> <20100423171216.GV10389@Sun.COM>
In-Reply-To: <20100423171216.GV10389@Sun.COM>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>, ietf@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 17:14:25 -0000

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.

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

v2.23.0 | Report a Bug | By Email