Re: [secdir] SecDir review of draft-hoffman-tls-master-secret-input-01

[Nicolas Williams <[e-mail]>]

On Mon, Apr 26, 2010 at 10:52:22PM +0300, Yaron Sheffer wrote:
> Having followed the discussion on the TLS and then the IETF mailing
> lists, I initially thought that this draft is harmless, while its
> companion draft draft-hoffman-tls-additional-random-ext-01 (ARE) is
> controversial. Having reread this draft, I now think there is no value
> in reviewing them separately. This draft does not mention ARE (although
> it should), but its sole raison d'etre is that other draft. In other
> words, they should be viewed as one proposal and, given that there is
> widespread criticism of the utility of ARE, I strongly recommend that
> both should be published as Experimental (rather than Proposed
> Standard).

IMO draft-hoffman-tls-master-secret-input-01 is useful as a tool to add
channel binding [RFC5056] to TLS.  I'm not sure that there ever will be
any uses for channel binding in TLS (re-negotiation, now that it's
fixed, does something like channel binding internally, but that's not
relevant here).

So I'm inclined to agree that draft-hoffman-tls-master-secret-input is
useless at this time.  ARE is definitely controversial, and possibly
harmful.

> Although the introduction does mention crypto binding, this document is
> clearly NOT about channel binding. CB is not mentioned as a motivation,
> and I don't see where this extension would add value for channel
> binding, compared to the existing Finished messages.

Indeed, Paul reject CB as a use for draft-hoffman-tls-master-secret-input
early on.  I don't understand why, exactly, other than the fact that
there's no need in sight to bind TLS to other channels -- but Paul did
not argue as much, IIRC.

> - Sec. 1: although this may be trivial, we should still say that only
> extensions that are understood by both peers participate in the
> calculation.

Good point.

> - I don't understand why the extensions are sorted by type number,
> instead of taken directly from the message, i.e. in the order they
> appear there. But I seem to remember this has already been hashed out on
> the list.

As long as there's a canonical order...

> - The notation in Sec. 2 is confusing: it is unclear whether the MS
> input can be computed, or whether it should appear explicitly in the
> extension fields in the messages. The notation
> ClientHello.additional_ms_input implies the latter, but this is not
> spelled out. If computed, the additional MS input should not necessarily
> be associated with the Client/Server Hello message. It could simply be a
> shared value common to both peers.

The extra ms input need not be sent (no extensions for sending them are
provided in this I-D).  Either both sides agree on what the extra inputs
must be, or additional extensions must be specified and used to
negotiate what those inputs are.

> - Given that this extension is intended to deal with faulty RNGs and
> presumably less than perfect PRFs, I think the simple concatenation of
> the input byte strings may be too easy to attack, if the extensions are
> variable length. For example, if additional MS input 1 (AMSI1) is "1234"
> and AMSI2="56", an attacker can play with the client-side extensions to
> achieve AMSI1="12" and AMSI2="3456", resulting in the same MS. One way
> to harden the computation is by adding a fixed delimiter between inputs,
> e.g. "/".

I'm very uncomfortable with ARE and the notion that larger randoms are
needed here.

> - Sec. 3: "The additional master secret input may have no entropy" -
> this seems to negate the only justification that was given for this
> protocol extension.

A CB need not add entropy (think of tls-server-endpoint).

> - Sec. 4: although the text is formally correct, it should still
> reference the ARE draft. In fact, if this section is planned to go away,
> the right place for this reference appears to be the Introduction.

Perhaps.

Nico
--