Re: [dsfjdssdfsd] Any plans for drafts or discussions on here?

<ietf@hosed.org> Thu, 23 January 2014 03:55 UTC

Return-Path: <jon@hosed.org>
X-Original-To: dsfjdssdfsd@ietfa.amsl.com
Delivered-To: dsfjdssdfsd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DED61A0183 for <dsfjdssdfsd@ietfa.amsl.com>; Wed, 22 Jan 2014 19:55:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level:
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb9udajLUUJg for <dsfjdssdfsd@ietfa.amsl.com>; Wed, 22 Jan 2014 19:55:01 -0800 (PST)
Received: from firefly.encrypted.net (firefly.encrypted.net [72.13.81.186]) by ietfa.amsl.com (Postfix) with ESMTP id 082AF1A0179 for <dsfjdssdfsd@ietf.org>; Wed, 22 Jan 2014 19:55:00 -0800 (PST)
Received: from firefly.encrypted.net (localhost [127.0.0.1]) by firefly.encrypted.net (Postfix) with ESMTP id DD6E41706E; Wed, 22 Jan 2014 19:54:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hosed.org; s=default; t=1390449300; bh=f6/ekX1XwJ2b+S7PoPvLkioBX//MiPanuAjjGCFNLQA=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=vRzrWndfZCndh9IYOBupcmDQccwCfawhfpM9Os73CQTt3htnDGTBf8WN5Joslm602 P8DWGtScUBSLK2cdtS8HCxBXehxm0yDTvVASGUrvIejxO2yV2gWDLetsh1UmvQ0KU9 xUuTRO+vKdcyeDNvi9M2l+qO7tpSZDaUCqM4WY3Y=
X-Virus-Scanned: amavisd-new at encrypted.net
Received: from firefly.encrypted.net ([127.0.0.1]) by firefly.encrypted.net (firefly.encrypted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSaiTxk_G2wS; Wed, 22 Jan 2014 19:54:59 -0800 (PST)
Received: from jgreent410s (76-220-43-250.lightspeed.sntcca.sbcglobal.net [76.220.43.250]) by firefly.encrypted.net (Postfix) with ESMTPA id 7817A17068; Wed, 22 Jan 2014 19:54:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hosed.org; s=default; t=1390449299; bh=f6/ekX1XwJ2b+S7PoPvLkioBX//MiPanuAjjGCFNLQA=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=RBBz1c6C1PcXka88qi3+sw7l/VFr+WW7mxYwfD7LGBs/Ec/7uXqM43XalK22UukkU fvJH7Hlp4ljItMZ1IqlX0Hb5r550yDehw1SYVDrAJwXpeONEYdaxtH7EgHa6hD77xC 1R7zyi+PG0ntu0j3+CRNLnG6GmEBiXpfNId4nRkU=
From: <ietf@hosed.org>
Sender: "Jon Green" <jon@hosed.org>
To: =?Windows-1252?Q?'Kriszti=E1n_Pint=E9r'?= <pinterkr@gmail.com>
References: <52DD996F.3040708@cs.tcd.ie> <CAF4+nEHEWaSr3HMuGtQ=vQzuuhkTo2uNpedUTNgmT5NsWRsTfA@mail.gmail.com> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com>
In-Reply-To: <1737731959.20140122185149@gmail.com>
Date: Wed, 22 Jan 2014 19:54:59 -0800
Message-ID: <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQG3sdi2ZRq1Hpg6dXIL/pF6U42SYgGC9VecARNdWnIB1CvuGpqdIaQg
Content-Language: en-us
Cc: dsfjdssdfsd@ietf.org
Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here?
X-BeenThere: dsfjdssdfsd@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 23 Jan 2014 03:56:01 -0000

I'm new to the list, so apologies if I go off the track here.

The problem with relying on the OS is that you're not always sure what the
OS is doing.  Example:  If I run Linux under ESXi on a headless server, with
an SSD for a disk, and I use the Ethernet NIC built into the motherboard,
where is the entropy for /dev/random coming from?  Is the driver for that
particular NIC instrumented to contribute to the entropy pool?  Most people
don't know, and further don't know how to find out.

I have seen embedded Linux products before where the sole source of entropy
was the hard disk.  Problem was, the entire system operated off a RAMdisk,
so guess how much disk activity there was during runtime?  

Those of us who deal with FIPS 140 and Common Criteria are now being asked
to document entropy sources, including providing measurements of how much
entropy is actually there and how fast it can be produced.  Looking at one
Common Criteria protection profile specifically - the VPN client PP - the
developer has the choice of generating cryptographic entropy within the
application, or relying on the underlying platform to supply it.  But the
only way you get to rely on the underlying platform is if that platform
itself has been through a PP evaluation and thus quantified the entropy.  So
if you want to have any hope of passing the evaluation, you're almost forced
into doing something yourself.

The various DRBGs are fine IMHO for handing out bits of random to an
application, and lacking anything better today I would certainly encourage
developers to use one.  But the question is how do we seed the DRBG in the
first place?  

-Jon


-----Original Message-----
From: dsfjdssdfsd [mailto:dsfjdssdfsd-bounces@ietf.org] On Behalf Of
Krisztián Pintér
Sent: Wednesday, January 22, 2014 9:52 AM
To: Paul Hoffman
Cc: Donald Eastlake; dsfjdssdfsd@ietf.org; Stephen Farrell
Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here?


Paul Hoffman (at Tuesday, January 21, 2014, 2:28:26 AM):
> It still feels very wrong
> for us to be suggesting to application developers that they should
> be doing their own randomness; they should be asking their OS unless
> they are experts, and those experts don't need an RFC.

(new to the list, and i'm not sure about the scope or context, so
forgive me if i'm talking nonsense.)

i agree that the OS should do the work, for multiple reasons, 1, it is
better done in a protected environment (aka ring 0), 2, OS has access
to more entropy, 3, better have one excellent than many good
solutions.

that said, what is the list of OS's today that has sound, reviewed
RNG? openbsd, ...? so this is pretty thin.

_______________________________________________
dsfjdssdfsd mailing list
dsfjdssdfsd@ietf.org
https://www.ietf.org/mailman/listinfo/dsfjdssdfsd