Re: [TLS] New drafts: adding input to the TLS master secret

Paul Hoffman <> Wed, 03 February 2010 04:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C55F53A67FA for <>; Tue, 2 Feb 2010 20:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.05
X-Spam-Status: No, score=-6.05 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e1t44WSCxvCp for <>; Tue, 2 Feb 2010 20:47:15 -0800 (PST)
Received: from (Balder-227.Proper.COM []) by (Postfix) with ESMTP id D278C3A67A8 for <>; Tue, 2 Feb 2010 20:47:15 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.2/8.14.2) with ESMTP id o134lrfA099866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 21:47:54 -0700 (MST) (envelope-from
Mime-Version: 1.0
Message-Id: <p0624083ec78eaacd96fa@[]>
In-Reply-To: <>
References: <p0624089bc78922bdaddd@[]> <> <p06240813c78e116da3f6@[]> <001001caa442$beefbde0$3ccf39a0$@org> <p06240829c78e37e5a850@[]> <001101caa44b$35f6f540$a1e4dfc0$@org> <p06240831c78e4f0e15ee@[]> <> <p0624083bc78e8c1563cc@[]> <>
Date: Tue, 2 Feb 2010 20:47:51 -0800
To: Marsh Ray <>, "" <>
From: Paul Hoffman <>
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [TLS] New drafts: adding input to the TLS master secret
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Feb 2010 04:47:16 -0000

At 9:26 PM -0600 2/2/10, Marsh Ray wrote:
>Let's say the server has a perfect RNG and the client is broken Debian Etch.
>The client provides 15 bits of usable entropy in the Client Hello, the
>server provides 224.
>RSA key exchange is negotiated.
>The client generates the 48-byte premaster secret with an effective
>entropy of less than 15 bits (his first handshake since power on).
>Game over, right?

Wrong. The master secret (the only one that matters for channel security) gets the advantage of all the randomness added by the client *and* the server. Without this extension, that is still probably acceptable for some uses; with the extension (if the server contributes more randomness), for all uses. Look again at section 8.1 in RFC 5246.

>I think similar effects apply with DHE key exchange.

Indeed. You will get half the expected randomness in the master secret.

> >> How big were you planning to make those symmetric keys anyway?
>> 48 bytes, as shown in the document.
>So at best there are 384 bits of entropy in play?


>Assuming the server supplies his expected 224, our Debian Etch client
>only has to pull together 160 usable BoE for them to hit that limit.

Or the server can contribute all that is needed, if you are using the proposed extension.

>I do appreciate a healthy safety margin, but there is some complexity
>overhead and potential security risk.

The complexity overhead is only paid for in systems that want to use these kinds of extensions. (Did I already say that?)

>Your point about "potentially would allow an attacker who had partially
>compromised the inputs to the master secret calculation greater scope
>for influencing the output" is significant.

So does the sentence that follows it: "Hash-based PRFs like the one used in TLS master secret calculations are designed to be fairly indifferent to the input size."

>Some kinds of hash attacks
>let the attacker mess with the bytes earlier in the handshake by placing
>colliding blocks in the Hello Extensions.

Are you saying that that affects the HMAC-based PRF calculation in TLS 1.2? If so, this is a pretty significant flaw in TLS that no one else has noticed. Note that there have been papers by well-known cryptographers saying that the HMAC construction does not have the weakness you ascribe to it here.

>It also requires clients and servers to buffer the stuff and later
>implement a sorting algorithm based on type order.

By "later" you mean "still within the same handshake sequence" and by "sorting algorithm" you mean "ascending order of two-byte numbers", yes?

>Lots could go wrong
>with that. Pathological sort order DoS attacks, etc.

Please explain further. The TLS spec says that you can only have one instance of an extension in a handshake. Thus, all TLS implementations today already should be looking for multiple instances of the same extension. What is left is a relatively small number of extension values, each of which has a unique two-byte number associated with it. Where does "pathological sort order DoS attacks" or "etc" come in?

--Paul Hoffman, Director
--VPN Consortium