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

[Nicolas Williams <[e-mail]>]

On Fri, Apr 23, 2010 at 07:13:14AM -0700, Paul Hoffman wrote:
> Hi again. It appears that people have a hard time with the additional
> random extension because it has limited applicability but I cannot
> fully state what that is. The purpose here is to help fix problems
> that shouldn't happen, and to be harmless when the bad situation
> doesn't happen. This has led some people to think that an implementer
> will therefore feel free to code more carelessly. I have a higher
> respect for TLS implementers, but maybe I shouldn't.

Why can't you add text explaining that this particular extension (as
opposed to master-secret-input generally) can only be used with certain
cipher suites and is intended only for the purpose of strengthening the
maste secret computation.  Stay away from discussions of entropy, except
to explain that any random octet strings sent in cleartext contain zero
entropy relative to attackers (since they can see it passively).

Also, if you insist on saying that this extension can add entropy, can
you explain what it does that the existing client_random and
server_random don't do?

> I am not sure that I can convince people of what seems like an obvious
> fact: the PRNG on a system might fail in a way that the TLS
> implementation cannot detect. If it could detect the failure, of
> [...]

Irrelevant: if the random octets being sent don't add entropy (because
they are sent in cleartext) then this extension is completely orthogonal
to PRNG failures.

Incidentally, I think this I-D should specifically mention that the
extension is a client and server Hello extension, which will help
clarify for the reader that it is sent in cleartext (except for
renegotiation, but note that when used in renegotiation this extension
still adds no entropy if the same key exchange was used on the outer
negotiation).

> I still believe that this extension itself is harmless in all cases,
> and helpful in limited ones; I have not seen anyone directly prove
> otherwise. Having said that, I'm of course willing to go along with
> IETF consensus if people think that the mere standardization of this
> extension will somehow weaken existing implementations.

I do believe it's mostly harmless; I am concerned that 2^16 max octets
seems like a bit much, possibly a source of DoS attacks.  I believe it's
also useless.  As such I'm not opposed to it as an Experimental or even
Informational RFC.

I'm opposed to putting known-useless things on the Standards Track.  I
don't feel too strongly about that: if the IESG and IAB don't mind
putting known-useless things on the Standards Track, I can live with
that, provided, in any case, that the decision to do so explicitly
considers the utility of known-useless Standards.

Note that I believe that draft-hoffman-tls-master-secret-input _is_
useful, and should be on the Standards Track (even if initially there
are no uses of it also on the Standards Track).

Nico
--