[Cfrg] randomness improvements via DHE/ECDHE, was: [Re: I-D Action: draft-irtf-cfrg-randomness-improvements-01.txt]

[Jason Cooper <[e-mail]>]

All,

On Mon, Jul 02, 2018 at 03:32:22PM -0700, [e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Crypto Forum RG of the IRTF.
> 
>         Title           : Randomness Improvements for Security Protocols
>         Authors         : Cas Cremers
>                           Luke Garratt
>                           Stanislav Smyshlyaev
>                           Nick Sullivan
>                           Christopher A. Wood
> 	Filename        : draft-irtf-cfrg-randomness-improvements-01.txt
> 	Pages           : 7
> 	Date            : 2018-07-02
> 
> Abstract:
>    Randomness is a crucial ingredient for TLS and related security
>    protocols.  Weak or predictable "cryptographically-strong"
>    pseudorandom number generators (CSPRNGs) can be abused or exploited
>    for malicious purposes.  The Dual EC random number backdoor and
>    Debian bugs are relevant examples of this problem.  This document
>    describes a way for security protocol participants to mix their long-
>    term private key into the entropy pool(s) from which random values
>    are derived.  This augments and improves randomness from broken or
>    otherwise subverted CSPRNGs.

As an engineer working with embedded / constrained systems, it's
refreshing to see this work.  Thanks!

I've not had the opportunity to contribute an RFC before, so I'm
unfamiliar with the process.  I'm interested in doing an extension /
follow-on to this RFC that would use ephemeral shared secrets derived
from DHE or ECDHE.

The scenario being: a constrained device, on first boot, empty entropy
pool.  It uses it's long-term private key to seed the pool as you've
outlined.

Then, to strengthen the pool, it does DHE/ECDHE negotiations with
multiple peers on it's local network.  The ephemeral shared secret from
each of those negotiations is then fed into the entropy pool.  How to do
this securely would be the bulk of the proposed RFC.

Questions the RFC would address:

 - Zero-credit is a safe default, what is a safe margin to credit the
   entropy pool for each shared-secret contribution, if any?

 - Threat model to mitigate: Network observer gaining info about the
   state of the pool.

 - Threat model to mitigate: One or more (all?) peers independently, in
   concert, or in concert with network observer using their knowledge of
   one or more shared secrets to gleen information about the state of
   the entropy pool.

 - Threat model to mitigate: One or more active attackers using chosen
   private/public ephemeral key pairs to manipulate the state of the
   entropy pool.  Possibly by flooding.  This could be limited to the
   number of connections initiated by the client desiring seeding
   material.  Resilience to this threat model would enable servers
   (connection receivers) to take advantage of this source as well.

 - Can this proposed RFC be relied on to 'X' security level independent
   of the long-term private key seeding RFC?  In other words, can it
   provide *any* security if it's the sole seeder of an entropy pool?

Is this a sane idea?  I'm leary of the fact that two parties know the
shared secret (by design), but I think it has good potential at least as
one of many seed sources to a pool.  At a minimum as a non-credit
"stirring" of an existing pool.

Any thoughts or insights would be much appreciated.

Thanks,

Jason.