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

Nicolas Williams <> Mon, 26 April 2010 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B6BF28C17C; Mon, 26 Apr 2010 14:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.062
X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=-1.878, BAYES_40=-0.185, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KMCSV2IrENxU; Mon, 26 Apr 2010 14:03:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 258F028C114; Mon, 26 Apr 2010 14:03:13 -0700 (PDT)
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3QL2u7o014736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Apr 2010 21:02:58 GMT
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3QIIpNC026056; Mon, 26 Apr 2010 21:02:54 GMT
Received: from by with ESMTP id 210397971272315713; Mon, 26 Apr 2010 14:01:53 -0700
Received: from Sun.COM (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Apr 2010 14:01:52 -0700
Date: Mon, 26 Apr 2010 16:01:48 -0500
From: Nicolas Williams <>
To: Yaron Sheffer <>
Message-ID: <20100426210146.GC10389@Sun.COM>
References: <1272311542.2347.64.camel@yaronf-linux>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1272311542.2347.64.camel@yaronf-linux>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: []
X-CT-RefId: str=0001.0A090209.4BD5FF82.011E:SCFMA4539811,ss=1,fgs=0
Cc: Paul Hoffman <>,,
Subject: Re: [secdir] SecDir review of draft-hoffman-tls-master-secret-input-01
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Apr 2010 21:03:14 -0000

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

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