Re: [TLS] New drafts: adding input to the TLS master secret

James Manger <James@Manger.com.au> Sat, 13 February 2010 10:27 UTC

Return-Path: <James@Manger.com.au>
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 9517628C0F4 for <tls@core3.amsl.com>; Sat, 13 Feb 2010 02:27:51 -0800 (PST)
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 OBrFROzUbUrs for <tls@core3.amsl.com>; Sat, 13 Feb 2010 02:27:50 -0800 (PST)
Received: from nskntmtas03p.mx.bigpond.com (nskntmtas03p.mx.bigpond.com [61.9.168.143]) by core3.amsl.com (Postfix) with ESMTP id 9EC7E3A78A4 for <tls@ietf.org>; Sat, 13 Feb 2010 02:27:49 -0800 (PST)
Received: from nskntotgx03p.mx.bigpond.com ([60.224.96.34]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20100213102911.LHRS16793.nskntmtas03p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com> for <tls@ietf.org>; Sat, 13 Feb 2010 10:29:11 +0000
Received: from [192.168.0.11] (really [60.224.96.34]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20100213102910.JCCO1978.nskntotgx03p.mx.bigpond.com@[192.168.0.11]> for <tls@ietf.org>; Sat, 13 Feb 2010 10:29:10 +0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
From: James Manger <James@Manger.com.au>
In-Reply-To: <mailman.105.1266004818.32764.tls@ietf.org>
Date: Sat, 13 Feb 2010 21:29:10 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A779139-AE11-4197-AAA0-372A73E5D949@Manger.com.au>
References: <mailman.105.1266004818.32764.tls@ietf.org>
To: tls@ietf.org
X-Mailer: Apple Mail (2.1077)
X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.4B767EF3.00E6,ss=1,fgs=0
Subject: Re: [TLS] New drafts: adding input to the TLS master secret
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: Sat, 13 Feb 2010 10:27:51 -0000

> I propose a design rule:   A PRNG should never be used to obtain a unique value.
> Instead a counter or a date should be used.



I propose a different design rule: A PRNG should always be preferred over a counter when a collision-free value is required.

Counters need their state to be retained to ensure uniqueness and maintaining state is very often a challenge for computer programs (across outages, across server farms, across saving VM images and restarting duplicates, across hot backups, across correcting the clock...)

For a PRNG output to be unique you just choose an appropriate output size.


Revisit the rule iff a new crypto result emerges undermining all known PRNG designs. 

--
James Manger