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

Nicolas Williams <Nicolas.Williams@oracle.com> Mon, 26 April 2010 17:28 UTC

Return-Path: <Nicolas.Williams@oracle.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 31E1A3A6967; Mon, 26 Apr 2010 10:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.209
X-Spam-Level:
X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-2.211, BAYES_50=0.001, UNPARSEABLE_RELAY=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 wjdj6O+LP-nH; Mon, 26 Apr 2010 10:28:30 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id CC2883A69EF; Mon, 26 Apr 2010 10:28:29 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3QHSDi9002301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Apr 2010 17:28:15 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3QG87Qp018044; Mon, 26 Apr 2010 17:28:11 GMT
Received: from abhmt003.oracle.com by acsmt353.oracle.com with ESMTP id 190629911272302796; Mon, 26 Apr 2010 10:26:36 -0700
Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Apr 2010 10:26:35 -0700
Date: Mon, 26 Apr 2010 12:26:29 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Marsh Ray <marsh@extendedsubset.com>
Message-ID: <20100426172628.GX10389@Sun.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> <4BD5C984.1040001@extendedsubset.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BD5C984.1040001@extendedsubset.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090207.4BD5CD30.0103:SCFMA922111,ss=1,fgs=0
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:28:31 -0000

On Mon, Apr 26, 2010 at 12:12:36PM -0500, 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.

This is true, but those are already plenty large enough.  If the
argument is that the client and server random from the TLS hellos are
not large enough, then let's hear that argument.

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

The right term for this might be "confounding" (but then, it's a term
I've only seen in use in the context of Kerberos).

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

Right.

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

2^182 bits of storage is not remotely a realistic number: it's about the
number of atoms in the Solar system (if I have my math right).

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

Actually, I withdraw the above quoted comment: it's already the case
that a hello can bear large extensions.

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

I also don't think that Paul intends that.

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

Yes, but since we do need nonces in our protocol, I think this is a
risk we have to live with.  What you are arguing for, IIUC, is that
nonces shouldn't be extremely large, but just right -- I agree with
this.

Nico
--