Re: 2nd version - Proposal for New Section 11.1 PRNG

["David M. Williams" <d_wllms%lanl.gov@localhost>]

Chrris,
   I hope that my signal-to-noise ratio on comments hasn't gotten too 
low that I can't make a few comments on the PRNG section.

Comments below:

> ============================================================
>
> 11.1 PRNG
the acronym PRNG lacks a parenthetical reference at it's first occurance 
in the draft.

s/PRNG/Pseudo-Random Number Generation/
with the parenthetical reference in the following paragraphs or

s/PRNG/Pseudo-Random Number Generator (PRNG)/
This is probably not correct per the style RFC.

also we seem to be using the acronym for both "generator" and 
"generation".  Do we care about the gramatical agreement?

>   This protocol binds each session key to the session by including
>   random data that is specific to the session in the hash used to
maybe this is clearer,
s/random data that is specific to the session/random, session specific data/

>   produce session keys.  If the random data here (e.g., DH parameters)
>   are pseudo-random then the PRNG should be cryptographically secure
>   (i.e., its next output not easily guessed even when knowing all
>   previous outputs) and, furthermore, entropy needs to be added to the
>   PRNG.  RFC 1750 [1750] offers suggestions for sources of entropy.
>   Implementors should note the importance of entropy and the well-meant,
>   anecdotal warning about the difficulty in properly implementing PRNG
>   functions.
s/PRNG functions/PRNGs/
fixes the usage issue, now all uses reflect the implied "generator" usage.

>   The amount of entropy available to a given client or server sometimes
>   may be less than what is needed to run the protocol.  In this case
s/sometimes may/may sometimes/

s/to run the protocol/to provide

>   one must either resort to PRNGs anyways or refuse to run the protocol.
s/anyways/regardless of insufficient entropy/

>   In practice implementors will generally rely on some PRNG.
I'd like to suggest we drop this sentence.

> [1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
>       Recommendations for Security", RFC 1750, December 1994.
>
>
>
>  

--
David M. Williams, CISSP		Phone: 505-665-8062
Systems Engineer, CCN-2			Fax:   505-667-7942
Los Alamos National Laboratory		Email: d_wllmsATlanlDOTgov

"Nel mezzo del cammin di nostra vita / mi ritrouvai per una selva oscura /
che la diritta via era smarrita" -Dante Aligheri