Randomness Requirements for Security
draft-eastlake-randomness2-10

[Ballot comment]
Reviewed by Elwyn Davies, Gen-ART

The review is entered into the comment log; there are a number of suggestions for clarification that should be heeded if the document is respun, but they are not show-stoppers.

Review by Elwyn Davies, Gen-ART:

Summary: This document appears to be in good shape for approval as BCP give or
take a few nits.  This is certainly a topic which deserves an updated BCP at
this time.  I am not a security expert but a brief trawl of the web seems to
indicate that the suggested techniques represent current best practice.  The
document could be improved by a short glossary of highly technical terms used in
discussion of randomness.  I am not sure that presenting the details of the
X9.82 algorithm in 7.2.1.x or other algorithms in 7.2.2 and 7.2.3 adds to the
value of the draft.  It would be worth mentioning that most of the hardware
generators rely on quantum effects and maybe that Intel have implemented a
thermal noise RNG in some (all?) of their recent x86 chipsets. The abstract is
overly long. There are a number of typos and language issues.

Review:
Generally the draft is in good shape and appears to cover the topic thoroughly
presenting what appear to be the real BCPs.

A small glossary would help with definitions of a few terms (randomness,
entropy, rate of entropy (?= Shannon Entopy Rate), de-skew, mixing, seed, FFT)
and there need to be expansions of a couple of acronyms at first appearance.

The abstract is overly long compared with guidelines.

Semi-substantive:
S2, para 12: It might be useful for less sophisticated readers to explain what
'entropy' is and why it is relevant.
S3, para 3:  Might be worth pointing out that the various hardware sources are
ultimately dependent on various manifestations of quantum uncertainty.  Also,
could be worth noting that a metal film resistor is an excellent thermal noise
source and can be readily integrated onto current VLSI chips making it an easy
choice for hardware integrated randomness choice.  Also that Intel has provided
such a source in at least some of its recent x86 support chipsets (especially
the 810 series).
S3, para 3: 'and a free-running oscillator'... sounds rather as if this is an
adjunct to the thermal nose or radioactive decay source.. maybe better formatted
as a list.
S3, para 3: 'Most audio (or video)... ' - I wondered why mouse or other use
input wasn't included here ... I found out that later that there are some
caveats but it might be worth including something like 'or mouse/tablet/keyboard
input devices (subject to some caveats)'.
S3.3, para 1: 'rate of entropy' needs to be defined... not sure if this is the
Shannon Entropy Rate but need to understand why this is important.
S3.3, para 1: Last sentence 'Another possibility...diode.' doesn't belong here. 
It should be with the thermal noise source at the beginning of S3.  Also it
should be pointed out that diode noise is more complex and needs more careful
treatment than straight thermal noise.
S3.3, para 3: the wording does not make it clear whether 'and extensive post
processing' is specified in 802.11i or whether the design should minimize the
needs for it (or something).
Ss7.2.1.x, 7.2.2 and 7.2.3:  Do the outlines of the algorithms quoted from the
standards referenced actually add anything to this draft at the risk of
misquoting or misleading?

Editorial/nits:
Need to run idnits on the document.
S1, para 2: Expand SSH, IPSEC, TLS, S/MIME, PGP, DNSSEC??
S2, para 1: s/on ordinary words/from ordinary words/
S2, para 6: Expand RSA (first occurrence).
S2, para 7: s/enough/sufficiently/
S2, para 7: s/succeeding at this/succeeding with this/
S2, para 9: s/ , before/, before/
S2, para 11: s/analysis where what/analysis: here what/
S2, para 13: s/Renyi entropy have/Renyi entropy has/,
            s/is Shannon entropy/is the Shannon entropy/
S2, para 15: s/. [CRC]/ [CRC]./
S3, para 2: s/that's/that is/
S3.6: para 1: s/a hardware/hardware/
S4.2, para 1: s/and described/as described/
S4.3:  FFT should be expanded and the expanded version used in the title.
S4.3, para 2: s/show/shown/
S5.1, para 1: s/show/shown/, s/  provides/ provides/
S5.3, last para: s/application/applications/
S6.1, para 1: s/idea/ideas/
S6.1.3, para 1: s/deterministic of/deterministic or/
S6.1.3, penultimate para: s/are released/is released/?
S6.2.1: use expanded forms of CTR and OFB in title.
S6.2.1, para 5: s/repeat/repeatedly/
S6.2.1, para 6: s/revealed each/revealed at each/
S7.1.3, para 2: s/all feed/all fed/
S7.2.1, para 1: s/generated/generator/
Ss 7.2.1.x:  The paragraph numbering is mangled. (7,2.1.1 -> 7.2.1.1, 7.1.2.2 ->
7.2.1.2, 7.2.1.5 -> 7.2.1.3)
S7.2.1.3, last para: s/stopping as soon a/stopping as soon as/,
                    s/and use the called/and using the called/,
                    s/calling from more/calling for more/
S8.2.1, para 3: s/vary much with they key/vary much with the key/

Don Eastlake is going to change the organization if the document in response to comments that were received from the IETF community.  This does not imply any technical changes, but this may make it harder to compare to previous versions.  I told Don to proceed since he believes that document will be improved.

Two extensive sets of comments were just recieved.  Yes, they are late.  Last call is over.  However, the comments came from credable sources, so I remoed the document from the 2004-09-16 telechat agenda to give the author time to consider the comments.

[Ballot comment]
Typos (non-ascii character conversion) in section 5:
s/All that?Ç–s needed/All that is needed/
s/system?Ç–s/system's/

5.2.2: s/1?Ç–s and 0?Ç–s/1's and 0's/

5.4: s/xor?Ç–ing/xor'ing/

and in other places.