Re: [dsfjdssdfsd] specifying an RNG

Eric Burger <eburger@standardstrack.com> Fri, 15 November 2013 10:56 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: dsfjdssdfsd@ietfa.amsl.com
Delivered-To: dsfjdssdfsd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8BE11E8189 for <dsfjdssdfsd@ietfa.amsl.com>; Fri, 15 Nov 2013 02:56:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.247
X-Spam-Level:
X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaBuX9kiYztX for <dsfjdssdfsd@ietfa.amsl.com>; Fri, 15 Nov 2013 02:56:00 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) by ietfa.amsl.com (Postfix) with ESMTP id B387C11E8181 for <dsfjdssdfsd@ietf.org>; Fri, 15 Nov 2013 02:55:53 -0800 (PST)
Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:54085 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <eburger@standardstrack.com>) id 1VhH3u-0005TZ-FV for dsfjdssdfsd@ietf.org; Fri, 15 Nov 2013 02:55:46 -0800
Content-Type: multipart/signed; boundary="Apple-Mail=_2B314021-F047-4117-94EA-8704DB73B08A"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Eric Burger <eburger@standardstrack.com>
X-Priority: 3 (Normal)
In-Reply-To: <f1fa93561577c1866315495de82b5437.squirrel@www.trepanning.net>
Date: Fri, 15 Nov 2013 05:55:39 -0500
Message-Id: <49FF9BED-3844-4D15-8F84-6E7231FE0892@standardstrack.com>
References: <f1fa93561577c1866315495de82b5437.squirrel@www.trepanning.net>
To: dsfjdssdfsd@ietf.org
X-Mailer: Apple Mail (2.1822)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [dsfjdssdfsd] specifying an RNG
X-BeenThere: dsfjdssdfsd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." <dsfjdssdfsd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dsfjdssdfsd>
List-Post: <mailto:dsfjdssdfsd@ietf.org>
List-Help: <mailto:dsfjdssdfsd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Nov 2013 10:56:11 -0000

On Nov 15, 2013, at 12:55 AM, Dan Harkins <dharkins@lounge.org> wrote:
>  Hello, and welcome to the dsfjdssdfsd list!
> 
>  At the last IETF the question was asked, "what can we do to harden
> the Internet?" Given the recent news about Dual_EC_DBRG and the
> dopant attack against hardware RNGs one of the things that can be
> done is to have an open specification of a secure RNG.

I like this idea.

> This would
> allow developers to have an alternative to relying solely on
> /dev/[u]random, a hardware RNG, an RNG specified by a large
> government-affiliated group to mix the uncorrelated sources of
> entropy they gather, or an RNG designed in an ad hoc manner by
> someone who thinks he knows what he's doing but probably
> doesn’t.

History is nice, but if we produce a *standard*, one would hope the developer goes to /dev/IETFrandom. I.e., none of the issues listed above are relevant.

>  One of the things that would be nice to get out of this list is a
> specification on a strong RNG, in the form of a BCP or Informational
> RFC. This doesn't necessarily mean lets "roll our own" but perhaps
> there is best practice that can be specified.

How is this any different than today’s practice? Today we point to NIST, FIPS, NSA, RSA, ISO, Government Committee of the Russia for Standards, etc.

>  So, is there a model that defines what a "robust RNG" would look
> like? Is there a suitable candidate that exists already for such a thing?

I am still having trouble understanding what would be different than what we do today. If you are proposing something akin to the open source codec work, then I am only just a bit skeptical, but I was proven wrong by that effort (it seems to be succeeding). However, if all we are doing is looking for a RNG to put into IETF standards, then are we not doing that already?