Message-ID: <20181101235035.GC25621@thunk.org>
Date:   Thu, 1 Nov 2018 19:50:35 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
Cc:     Kurt Roeckx <kurt@...ckx.be>, 912087@...s.debian.org,
        "Package Development List for OpenSSL packages." 
        <pkg-openssl-devel@...oth-lists.debian.net>,
        linux-kernel@...r.kernel.org,
        Bernhard Übelacker <bernhardu@...lbox.org>,
        pkg-systemd-maintainers@...ts.alioth.debian.org,
        debian-ssh@...ts.debian.org, 912087-submitter@...s.debian.org
Subject: Re: Bug#912087: openssh-server: Slow startup after the upgrade to
 7.9p1

On Thu, Nov 01, 2018 at 11:18:14PM +0100, Sebastian Andrzej Siewior wrote:
> Okay. So you wrote what can be done for a system with HW-RNG/kvm. On
> bare metal with nothing fancy I have:
> [    3.544985] systemd[1]: systemd 239 running in system mode. (+PAM…
> [   10.363377] r8169 0000:05:00.0 eth0: link up
> [   41.966375] random: crng init done
> 
> which means I have to wait about half a minute until I can ssh into. And
> there is no way to speed it up?

So that surprises me.  Can you tell me more about the hardware?  Is it
something like a Rasberry Pi?  Or is it an x86 server or desktop?  In
my experience for most x86 platforms this isn't an issue.

The main reason why I've talked about VM system is because this is
where it where most of the problems that people ahve reported to me.

Here's the problem: if we "speed it up" inappropriately, you're
risking the security of the ssh.  If people who are making a print
server or Wifi Rounter who screw it up, they're the ones who are at
fault.  (And this isn't hypothetical.  See https://factorable.net)

So if I make a blanket recommendation, and it causes Debian to ship
some kind of default that causes Debian users to be insecure, I'm
going to be feel really bad.  This is why I'm very cautious about what
I say.  If you want to do whatever you want on your own system, hey
consulting adults can do whatever they want.  :-)

> You did not oppose RNDADDTOENTCNT/RNDADDENTROPY but you wanted to make
> it configureable and not default, correct?

I'd want to see a full design doc, or a git repository, or set of
changes before I give it an unqualified endorsement, but there *are*
configurations where such a thing would be sane.

That's the problem with security recommendations.  It's much like a
lawyer giving legal advice.  They're very careful about doing that in
an unstructured circumstances.  If it gets taken in the wrong way,
they could be legally liable and people might blame/sue them.

And then on top of that, there are the political considerations.
Suppose I told you, "just use RDRAND and be happy".  Some people who
sure that RDRAND has been backdoored would claim that I'm in the
pocket of the NSA and/or Intel.  That's why all I'm going to say is,
"I'm comfortable turning RDRAND on my own systems; you can do what you
want."

Cheers,

						- Ted

P.S.  Although if I were going to generate a high-value key, I *would*
plug in my handy-dandy Chaos Key[1] first.  Keith gave a
presentation[2] about it at Debconf 16.

[1] https://keithp.com/blogs/chaoskey/
[2] https://debconf16.debconf.org/talks/94/

And certainly if you were doing something where you had millions of
dollars at risk, or where the EU might fine you into oblivion for
millions of Euros due to some privacy exposure of your users, I
certainly would recommend that you spend the $40 USD to get a Chaos
Key and just be *done* with it.

Powered by blists - more mailing lists