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

From: Yaron Sheffer <[email-masked]>
Date: Mon, 26 Apr 2010 22:52:22 +0300

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

General

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

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.

Details

- Quoting from TLS 1.2: "In general, the specification of each extension
type needs to describe the effect of the extension both during full
handshake and session resumption." I think a similar sentence should be
included here, and extensions should explicitly define their behavior
with respect to MS calculation in the case of session resumption.

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

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

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

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

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

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

---

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

> both should be published as Experimental (rather than Proposed

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.

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

> extensions that are understood by both peers participate in the

Good point.

> appear there. But I seem to remember this has already been hashed out on

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

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

> to harden the computation is by adding a fixed delimiter between inputs,

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

> this seems to negate the only justification that was given for this

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

> the right place for this reference appears to be the Introduction.

Perhaps.

Nico
--