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

Nicolas Williams <Nicolas.Williams@oracle.com> Tue, 27 April 2010 17:37 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 AB5E03A6A2B; Tue, 27 Apr 2010 10:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.23
X-Spam-Level:
X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-1.121, BAYES_05=-1.11, 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 0RLwiXQZy4BM; Tue, 27 Apr 2010 10:37:34 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6FAF03A688E; Tue, 27 Apr 2010 10:37:29 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3RHb6l3007130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Apr 2010 17:37:07 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3RHb044015454; Tue, 27 Apr 2010 17:37:01 GMT
Received: from abhmt009.oracle.com by acsmt355.oracle.com with ESMTP id 194241711272389772; Tue, 27 Apr 2010 10:36:12 -0700
Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Apr 2010 10:36:12 -0700
Date: Tue, 27 Apr 2010 12:36:07 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Dean Anderson <dean@av8.com>
Message-ID: <20100427173607.GR10389@Sun.COM>
References: <20100426213634.GD10389@Sun.COM> <Pine.LNX.4.44.1004270609590.14455-100000@citation2.av8.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.1004270609590.14455-100000@citation2.av8.net>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet15.oracle.com [148.87.113.117]
X-CT-RefId: str=0001.0A090202.4BD720C4.012F:SCFMA4539811,ss=1,fgs=0
Cc: tls@ietf.org, ietf@ietf.org, Paul Hoffman <paul.hoffman@vpnc.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: Tue, 27 Apr 2010 17:37:35 -0000

On Tue, Apr 27, 2010 at 06:23:13AM -0400, Dean Anderson wrote:
> On Mon, 26 Apr 2010, Nicolas Williams wrote:
> > On Mon, Apr 26, 2010 at 04:18:33PM -0500, Marsh Ray wrote:
> > > The draft was said to strengthen some properties of the protocol,
> > > particularly entropy in the RNG. In order to evaluate the draft, we need
> > > to agree on what those properties are supposed to be and how they affect
> > > the different protocol structures.
> > 
> > By analogy to legal review, if we don't need to reach the issue, then we
> > don't need to discuss it.
> >
> > RNG/PRNG matters either apply, in which case we can might in, or they
> > don't.  
> 
> The subject of entropy of PRNGs is substance of the draft.

If we knew what the extension was for then we could consider the
rationale for it in detail; but we don't.  The I-D is too thin.  This is
my main objection to the I-D _at this time_.

> The only way not to reach a question about substance is to not even get
> to the contents of the draft for some other reason (e.g. procedural
> objection). But you have no such objection, and no reason not to get to
> an analysis of the contents of draft, so there is no reason to avoid
> analysis of the substance.

That's not right.  If the I-D explicitly stated that the purpose for
this extension was to strengthen TLS key exchange by adding more entropy
we could then discuss whether adding more "random" octets from the same
source could help, long, long before we got to examine the source in
detail.  The reason is that either your RNG is good enough or it's not,
and if it's not then we should assume that adding more "random" octets
to the protocol is likely to _hurt_ more than help.  The assumption in
the previous sentence is all we need to know about RNGs for this
discussion.

By analogy to legal processes, there are ways to avoid reaching an issue
that are not procedural.

Nico
--