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

[Yaron Sheffer <[e-mail]>]

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.