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

Yaron Sheffer <yaronf.ietf@gmail.com> Mon, 26 April 2010 19:52 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 2BA093A69EE; Mon, 26 Apr 2010 12:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5CPVYZprrhJZ; Mon, 26 Apr 2010 12:52:48 -0700 (PDT)
Received: from fg-out-1718.google.com (fg-out-1718.google.com []) by core3.amsl.com (Postfix) with ESMTP id B08223A69C2; Mon, 26 Apr 2010 12:52:47 -0700 (PDT)
Received: by fg-out-1718.google.com with SMTP id l26so470367fgb.13 for <multiple recipients>; Mon, 26 Apr 2010 12:52:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=F2QZqa0vqEzZ76HiyJCudb+M2HjCjuqdmug+v5lS0pE=; b=F23NMZIAWP8Xoe2KBe7fkmkcorjRTDiP37roCkz1b0HD8Uk/qMSC9xNq5rfsX8vtf/ jcCG+n/oqvCEjmFt2qkQX1jkwOhKl+4mnKhR6cnspxtEfpvyE0xrKGQFKB625JwEM5Yg ++JZBUsb9HUydonyApHPzN2NrzssS2YN/puVo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=p/fhJjw/k44ZbYwwHdN5h26rCgV3wyAteNFVKoxOBrbYWbI2tda018SaVqEc4BdtsI bS34+EoSr6rJ73wpsWFwOokKMP/OVKdXIZN9O1TmcbfNUdzoceRShvlOmq1KceKux6gE 1P+ODnn5CR06Q7YV7I0DdlsYc9Ye1rVgndtDM=
Received: by with SMTP id w29mr3015578fgk.35.1272311549014; Mon, 26 Apr 2010 12:52:29 -0700 (PDT)
Received: from [] (bzq-79-181-18-85.red.bezeqint.net []) by mx.google.com with ESMTPS id 31sm5101566fkt.19.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 12:52:28 -0700 (PDT)
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: iesg@ietf.org, secdir@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 26 Apr 2010 22:52:22 +0300
Message-ID: <1272311542.2347.64.camel@yaronf-linux>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1
Content-Transfer-Encoding: 7bit
Subject: [secdir] SecDir review of draft-hoffman-tls-master-secret-input-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Apr 2010 19:52:49 -0000

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.


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

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.


- 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

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