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

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