ietf
[Top] [All Lists]

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

2010-04-27 13:16:38
On Mon, Apr 26, 2010 at 04:18:33PM -0500, Marsh Ray wrote:
Taking ietf(_at_)ietf(_dot_)org 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
ietf(_at_)ietf(_dot_)org(_dot_)  If anything, we might want to drop 
tls(_at_)ietf(_dot_)org(_dot_)

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.

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).
Paul?

Nico
-- 
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf