>>>>> "Benjamin" == Benjamin Kaduk <ka...@mit.edu> writes:
Benjamin> On Mon, May 07, 2018 at 05:10:27PM +0100, Ben Hutchings wrote:
>> On Mon, 2018-05-07 at 11:57 -0400, Sam Hartman wrote:
>>
>> There are basically three "strengths" of random numbers available
>> now:
>>
>> Weak: /dev/urandom Medium: getrandom(flags=0) Strong:
>> /dev/random, getrandom(flags=GRND_RANDOM)
>>
>> k5_get_os_entropy() has switched from weak/strong depending on
>> the "strong" flag to always medium. I think what you actually
>> want is medium/strong.
Benjamin> At high risk of opening up the RNG debate that I did not
Benjamin> want to revisit, the current stance of upstream krb5 seems
Benjamin> to fall into what I'll call the "Schneier worldview", that
Benjamin> a fully-seeded well-designed CSPRNG can produce arbitrary
Benjamin> amounts of random output with no need to track "entropy
Benjamin> depletion" or similar (emphasis on fully-seeded). So the
Benjamin> question (for them) is not "strong" or "weak", but rather
Benjamin> "fully seeded" or "not seeded yet".
OK, I'm happy with this model. It's certainly along the lines of what I
had in mind when I wrote some of the interfaces we're talking about.
Benjamin> In this worldview, if
Benjamin> you have to choose between /dev/random and /dev/urandom,
Benjamin> (1) /dev/random is the only thing that actually provides
Benjamin> the guarantee you want, but (2) /dev/random is incredibly
Benjamin> painful for using "all the time", so you're tempted to use
Benjamin> /dev/urandom for cases where it's "less important", like
Benjamin> session keys, but reserve /dev/random for times when you
Benjamin> really care about the "fully seeded" property, like
Benjamin> long-term keys. When those were the only choices, the
Benjamin> 'strong' flag made sense.
Benjamin> Now, we have getrandom(), which is a great API and is
Benjamin> pretty much exactly what you want (again, at least in this
Benjamin> worldview). IIUC Ted says that you should "just use
Benjamin> getrandom" for your entropy needs and not worry about
Benjamin> /dev/*random. I don't know whether he takes a stance on
Benjamin> the GRND_RANDOM flag, though.
And I think that's fine for kadmind.
I think there's a very real practical question about whether you want
the KDC to fail to start if your RNG is not seeded.
Having your KDCs be unavailable from a cold start of an environment is a
really big thing.
Benjamin> Anyway, I mention this all in the hope that we can just
Benjamin> drop this line or discussion and let upstream krb5 decide
Benjamin> what properties they want from a CSPRNG, and not try to
Benjamin> revisit that design.
To the extent that it impacts our jobs as system integrators to actually
provide an enterprise system that has availability, I don't think we
can.
Benjamin> To answer Sam's questions, in the above worldview, the
Benjamin> right answer for the KDC and the right answer for kadmind
Benjamin> are the same -- just use getrandom(). It provides the
Benjamin> output of a high-quality CSPRNG, and is guaranteed to
Benjamin> block until fully seeded. In this worldview, the
Benjamin> cryptographic quality of the (fully seeded) urandom pool
Benjamin> is more than adequate, so there's no need to ever pass
Benjamin> GRND_RANDOM.
To be clear I'm fine with that as far as it goes.
My concern is simply that we (Debian) need to consider the availability
question.
I know that upstream did not seriously consider that question when we
first adopted the Schneier world view. I don't know if upstream has
adequately considered that since, and if they have whether their design
tradeoffs are the same as we as Debian have.
I do really appreciate your reframing the question though because I
think availability vs strength will be an easier design discussion than
quality of random numbers and entropy.
Benjamin> I'm certainly open to having krb5 ship a proof-of-concept
Benjamin> wait-for-entropy.service in unstable for a while, though
Benjamin> it seems like something better suited for libc or systemd
Benjamin> core for the long term.
Benjamin> If we need to for stretch, it would presumably be easy
Benjamin> enough to just add a stanza to the KDC's unit file to
Benjamin> increase the timeout (though how do we know what sort of
Benjamin> timeout is "long enough"?).
Agreed.
