Re: [dsfjdssdfsd] what not to do...

Theodore Ts'o <> Wed, 02 April 2014 19:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C53071A03B3 for <>; Wed, 2 Apr 2014 12:10:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.801
X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ToZX5XhCkCiA for <>; Wed, 2 Apr 2014 12:10:36 -0700 (PDT)
Received: from ( [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by (Postfix) with ESMTP id B9E011A03B1 for <>; Wed, 2 Apr 2014 12:10:36 -0700 (PDT)
Received: from root ( by with local-esmtp (Exim 4.80) (envelope-from <>) id 1WVQYR-0002j0-6o; Wed, 02 Apr 2014 19:10:31 +0000
Received: by (Postfix, from userid 15806) id 80C6F5803BC; Wed, 2 Apr 2014 15:10:28 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1396465828; bh=sAMB6SavwmPvHdFpQGrNtJbv3JXPYSFPnevY/qhnxSE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aEjaCuXG+C8cPFJpG71MirFLjJqAomwxVfb5bk+4F/ZG7ahDR8swvVmFOQIXySTdv qagzPMtkzLMtmoTExZ34JsVfGcivFW/BDqOrHwRevCCS/iapDWrKdV4WKqK8+dwKnl tEyxSp2I+JtgmEMpeKg1aLd9tpa3T8T7A9qJTfGw=
Date: Wed, 2 Apr 2014 15:10:28 -0400
From: Theodore Ts'o <>
To: Dan Harkins <>
Message-ID: <>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Cc: "" <>, Paul Hoffman <>
Subject: Re: [dsfjdssdfsd] what not to do...
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Apr 2014 19:10:41 -0000

On Wed, Apr 02, 2014 at 11:32:37AM -0700, Dan Harkins wrote:
>   Donald is updating an existing RFC and I think the target audience for his
> update is the same as that of the existing RFC.

Well, the current language doesn't say who is the intended audience,
and the there may be people who will be reading this that aren't who
we think should be the intended audience.  So being explicit about
this might be good.  (BTW, what do *you* think the target audience of
the current text is?)

It might also be good to have some explicit advice for different
audiences.  For example, "If you are a SOC designer, you should
include a hardware RNG, and please see FOO_REFERENCE for details about
how to create a competent hwrng."

Or, "If you are an application programmer, and your system has a
random number facility, then unless there is a really good reason not
to, you should probably use the OS's rng instead of trying to roll
your own (since you probably will get it wrong).  Alternatively, if
your crypto library has a RNG, you should use that, so long as it is
documented to be for cryptographic purposes and you have initialized
it properly per its instructions."

>   My hope is that another draft will be written that specifies a strong RNG
> and the target audience for that would be people writing security code,
> especially for embedded OSs that have a more blurred line between kernel
> and application.

There's an awful lot in Donald's current text which covers this
particular area already.  In fact, I'd be really worried if other
audiences (i.e., application programmers) were going to try to measure
disk timing in their application code per the instructions in RFC

So I'm not sure it makes sense to have two different drafts.  I'd
suggest being explicit about which pieces of its advice is more
suitable for different audiences.


					- Ted