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

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Apr 2010 17:15:47 -0500

On Mon, Apr 26, 2010 at 05:10:35PM -0500, Marsh Ray wrote:
> On 4/26/2010 4:36 PM, Nicolas Williams wrote:
> > Ah!  Perhaps what's happening here is that Paul intends for the
> > additional random inputs to be provided by the _application_, from
> > outside the TLS implementation.  In that case an application could make
> > secure use of TLS even when the underlying TLS implementation has a poor
> > [P]RNG.  That would make draft-hoffman-tls-additional-random-ext much
> > more interesting (combined with some editing I'd drop my objections).
> 
> But that facility could be provided by the implementation API without
> any need to extend the TLS protocol. Indeed, OpenSSL provides a function
> to contribute entropy into its RNG.

There is a lot of inertia in installed base.  If there are
implementations that allow for arbitrary extensions then Paul would have
acase.  However, I suspect there are not; unless I'm missing something
then I agree with this:

> Thus I do not think draft-hoffman-tls-additional-random-ext should be
> advanced as a standard.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Apr 2010 16:36:34 -0500

On Mon, Apr 26, 2010 at 04:18:33PM -0500, Marsh Ray wrote:
> Taking [email-masked] off of CC list as this seems to be very TLS specific.

This is an IETF LC, not a WG LC; IETF LC comments should be sent to
[email-masked].  If anything, we might want to drop [email-masked].

> 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.

By analogy to legal review, if we don't need to reach the issue, then we
don't need to discuss it.

RNG/PRNG matters either apply, in which case we can might in, or they
don't.  I believe it is correct to assert that we don't need to discuss
[P]PRNGs in detail, or even at all if we agree that the existing TLS
client_random and server_random fields are sufficient.

Thus ISTM that we should first consider either whether the client_random
and server_random fields are sufficient _assuming_ compliant [P]RNGs or
consider how draft-hoffman-tls-additional-random-ext can ameliorate TLS
implementations that have poor [P]RNGs.

Paul?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Apr 2010 15:38:32 -0500

How is the sub-thread on RNGs and PRNGs relevant here?  If nodes don't
have good enough RNGs/PRNGs/seeds then draft-hoffman-tls-additional-
random-ext won't help.  If they do have good enough RNGs/PRNGs/seeds
then the existing client and server randoms are good enough.  Either way
draft-hoffman-tls-additional-random-ext adds nothing.  Or, what am I
missing?

(The RNG discussion is worth having, don't get me wrong, just not in
this context.)

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Mon, 26 Apr 2010 17:10:35 -0500

> [email-masked].  If anything, we might want to drop [email-masked].

That makes sense.

> implementations that have poor [P]RNGs.

I think the current space in the protocol of 224-256 bits in each
direction is sufficient. Well-known techniques exist for compressing
whatever format of entropy is available into that space.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 26 Apr 2010 12:47:01 -0700

Marsh Ray wrote:
> 
> http://tools.ietf.org/html/rfc2246 :
>> 7.4.1.2. Client hello
>>
>> [...]
>>
>>    random_bytes
>>        28 bytes generated by a secure random number generator.
> 
> Not pseudorandom, "generated by a secure random number generator".

No, if you look at the implementation notes in RFC 5246, you will see that
it really is meant to be pseudo-random:

    Appendix D.  Implementation Notes

    D.1.  Random Number Generation and Seeding

       TLS requires a cryptographically secure pseudorandom number generator
       (PRNG).  Care must be taken in designing and seeding PRNGs.  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.

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.

In my own implementation, the only place I use a true RNG is when a client
generates an RSA premaster secret.  (It may also get used in EDH when
generating private keys, but that happens internal to OpenSSL, and I haven't
looked at that code.)

Mike