Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random

[Marsh Ray <[e-mail]>]

Taking [e-mail] off of CC list as this seems to be very TLS specific.

On 4/26/2010 2:47 PM, Michael D'Errico wrote:
> 
> No, if you look at the implementation notes in RFC 5246, you will see that
> it really is meant to be pseudo-random:

I believe this wording is particularly unfortunate and needs to be fixed.

Perhaps Ekr will weigh in on this?

Here's my interpretation:

>    Appendix D.  Implementation Notes
> 
>    D.1.  Random Number Generation and Seeding
> 
>       TLS requires a cryptographically secure pseudorandom number generator
>       (PRNG).

Yes, it does.

Note that this does not modify the definition of random_bytes as
"28 bytes generated by a secure random number generator."

> Care must be taken in designing and seeding PRNGs.

Yes, it must.

Note the term "seeding".

> PRNGs
>       based on secure hash operations, most notably SHA-1, are acceptable,
>       but cannot provide more security than the size of the random number
>       generator state.

None of this is literally untrue, but the placement of this whole
paragraph seems to confuse the RNG/PRNG distinction.

I believe it was expected that the reader would understand that a True
RNG was being talked about. It seems to be taken for granted that this
will follow the conventional implementation of as pool of bits
containing sufficient entropy which is stirred by a strong
hash-function-based PRNG.

Places in the spec that need the "pseudo" generator define a
"pseudorandom function (PRF)" and use that term. The TLS 1.1 spec
refererences:
>    [RANDOM]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
>               "Randomness Requirements for Security", BCP 106, RFC 4086,
>               June 2005.
which I intend to read immediately.

> A server especially would not want to use an RNG (over a PRNG) since an
> attacker could rob it of all its entropy by sending a flood of bogus
> ClientHellos.

You need a good true RNG to implement TLS securely.

You shouldn't worry about it "running out of entropy". That it won't is
inherent in the definition of "good true RNG" as a primitive operation.
Another way of saying it is: if you're worried about running out of
entropy then fix your RNG, don't weaken the protocol implementation.

If you dump enough entropy* in the pool and stir it and extract it using
a strong hash function, the attacker can't reverse its state. This
fascinating topic is treated at length in "the literature" and I learned
a lot last time this thread came up.

*I think we've established that 2**224 is "probably enough".

> In my own implementation, the only place I use a true RNG is when a client
> generates an RSA premaster secret.

Are you saying that your client_hello and server_hello are predictable?
Better fix that.

On 4/26/2010 3:38 PM, Nicolas Williams wrote:
> How is the sub-thread on RNGs and PRNGs relevant here?

The draft was said to strengthen some properties of the protocol,
particularly entropy in the RNG. In order to evaluate the draft, we need
to agree on what those properties are supposed to be and how they affect
the different protocol structures.

It looks like the TLS RFCs are a bit unclear. From the comments, it
would appear that not all implementers have interpreted the spec in the
same way as it relates to true RNGs, PRNGs, the PRF, etc.

- Marsh