Re: Waiting for Randot (or: nia and maya were right and I was wrong)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sat, 16 Jan 2021 14:34:47 +0200
> From: Andreas Gustafsson <gson%gson.org@localhost>
> 
> Even if the unblocking criteria of Linux and FreeBSD are questionable,
> they still provide more security than your proposal which amounts to
> having extremely strict criteria but then completely ignoring.

This is not accurate.  The strict criterion is still available _for
system integration_, which is where the problem needs to be solved
anyway, just like other security measures like securelevel and
fetch_pkg_vulnerabilities.

The effect of making _applications_ just hang like this is that it
confuses everyone involved and breaks builds, because in practical
terms nothing is going to unblock them until the operator plugs in a
USB HWRNG or equivalent and it is not helpful to ask every application
to include logic that meaningfully prompts the user to do so.

> >    Such an application, like a Python program in the middle of just doing
> >    `import multiprocessing', is not in a position to remedy the situation
> >    or even usefully alert an operator to the problem.
> 
> Which is why we should deal with the issue by creating an entropy seed
> at the time of installation or first boot.

We already do this, and it incorporates any entropy obtained during
the installation process.

This will include keystroke timings during installation, and hundreds
of samples of a makeshift ring oscillator on each boot, if the
hardclock timer interrupt and CPU cycle counter or system timecounter
are driven by independent clocks.  Of course, it is hard to tell for
sure whether this is the case from MI software -- so it remains best
effort, without a confidently positive assessment.

> To start with, we should re-enable the code Martin already added to
> sysinst to prompt the user for missing entropy at install time, and we
> should continue to work on making it easier to use.

It's not just a prompt -- it will make users feel _trapped_ and hate
the whole thing, in an installer that already has too many mandatory
incomprehensible questions.  As a matter of user experience, a
mandatory question like this that gets in the way of doing anything
else is a dead end.

Security features that paternalistically prevent people from getting
things done will drive them to workarounds that defeat the security.

> We should also provide more entropy sources with conservative but
> nonzero estimates to make those prompts increasingly rare.

I would be happy to consider literature with conservative assessments
of these entropy sources if you have any references!

But a year after drafting the changes, nobody has provided such
references, and many people have run into practical problems that the
system in place is not conducive to fixing.

That's why, based on the experience, I'm trying a different approach:
provide clear hints and nudges where there may be a problem, without
making anyone feel trapped and resentful toward the issue, and without
causing apparently unrelated things to break on principle.