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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 03 February 2010 04:47 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55F53A67FA for <tls@core3.amsl.com>; Tue, 2 Feb 2010 20:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.05
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1t44WSCxvCp for <tls@core3.amsl.com>; Tue, 2 Feb 2010 20:47:15 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D278C3A67A8 for <tls@ietf.org>; Tue, 2 Feb 2010 20:47:15 -0800 (PST)
Received: from [75.101.18.87] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (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 paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0624083ec78eaacd96fa@[75.101.18.87]>
In-Reply-To: <4B68ECF3.5030707@extendedsubset.com>
References: <p0624089bc78922bdaddd@[10.20.30.158]> <87fx5jk8vp.fsf@mocca.josefsson.org> <p06240813c78e116da3f6@[75.101.18.87]> <001001caa442$beefbde0$3ccf39a0$@org> <p06240829c78e37e5a850@[75.101.18.87]> <001101caa44b$35f6f540$a1e4dfc0$@org> <p06240831c78e4f0e15ee@[75.101.18.87]> <4B68D672.2060609@extendedsubset.com> <p0624083bc78e8c1563cc@[75.101.18.87]> <4B68ECF3.5030707@extendedsubset.com>
Date: Tue, 2 Feb 2010 20:47:51 -0800
To: Marsh Ray <marsh@extendedsubset.com>, "tls@ietf.org" <tls@ietf.org>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [TLS] New drafts: adding input to the TLS master secret
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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?

Yes.

>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