Last Call Review of draft-hoffman-tls-master-secret-input-
|Requested revision||No specific revision (document currently at 03)|
|Type||Last Call Review|
|Team||Security Area Directorate (secdir)|
|Authors||Paul E. Hoffman|
|I-D last updated||2010-04-27|
Secdir Last Call review of -??
by Yaron Sheffer
|Request||Last Call review on draft-hoffman-tls-master-secret-input by Security Area Directorate Assigned|
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.