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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 03 February 2010 15:53 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 B2CB03A6C63 for <tls@core3.amsl.com>; Wed, 3 Feb 2010 07:53:03 -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 WfJ66h3XEZqz for <tls@core3.amsl.com>; Wed, 3 Feb 2010 07:53:02 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D58853A6C61 for <tls@ietf.org>; Wed, 3 Feb 2010 07:53:02 -0800 (PST)
Received: from [10.20.30.158] (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 o13Frg5b045994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Feb 2010 08:53:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240803c78f496c7732@[10.20.30.158]>
In-Reply-To: <4B6993F1.9000503@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> <p0624083ec78eaacd96fa@[75.101.18.87]> <4B6993F1.9000503@extendedsubset.com>
Date: Wed, 03 Feb 2010 07:53:43 -0800
To: Marsh Ray <marsh@extendedsubset.com>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: "tls@ietf.org" <tls@ietf.org>
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 15:53:03 -0000

At 10:19 AM -0500 2/3/10, Marsh Ray wrote:
>Paul Hoffman wrote:
>> 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.
>
>Sure but MitM knows all that because it's sent in the clear. The only
>thing MitM doesn't know in this scenario is the private key to the
>server's cert. So if the premaster secret is predictable (only 32k
>possibilities or so), it doesn't matter if it's well encrypted to the
>server's cert. A passive attacker can work out the master secret.

Boy, did I misinterpret your "Game over" question. I assumed you were talking about the amount of randomness in the master secret, not the amount of secrecy. OF COURSE adding public randomness to a value with low secrecy and low randomness only adds randomness, not secrecy. You can't magically generate cryptographic secrecy with public values.

If by "game over", you meant for secrecy, yes of course. The SSL world already discovered that with the Netscape SSLv2 debacle.

Let me try again: the proposal in draft-hoffman-tls-additional-random-ext is to add *randomness* to the master secret, not more secrecy. If I have said anything in the draft that makes that unclear, by all means let me know and I will fix it.


--Paul Hoffman, Director
--VPN Consortium