Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 22 April 2010 14:34 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 26D763A6C14; Thu, 22 Apr 2010 07:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.541
X-Spam-Level:
X-Spam-Status: No, score=-1.541 tagged_above=-999 required=5 tests=[AWL=-2.095, BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
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 E3+g8fqGpJY7; Thu, 22 Apr 2010 07:34:04 -0700 (PDT)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id AC9BA3A6B93; Thu, 22 Apr 2010 07:30:01 -0700 (PDT)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o3METmqk032696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2010 07:29:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240803c7f60d8cde2c@[10.20.30.249]>
In-Reply-To: <87fx2oxvua.fsf@mocca.josefsson.org>
References: <201004212205.o3LM5pwQ019241@fs4113.wdf.sap.corp> <p06240887c7f52b14f905@[10.20.30.158]> <87fx2oxvua.fsf@mocca.josefsson.org>
Date: Thu, 22 Apr 2010 07:29:46 -0700
To: Simon Josefsson <simon@josefsson.org>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
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: Thu, 22 Apr 2010 14:34:05 -0000

At 12:51 AM +0200 4/22/10, Simon Josefsson wrote:
>In which environments is the extension useful?
>
>The only motivation in the document that I can find is this:
>
>  In some application environments, it is desirable to have the client
>  and/or the server be able to input more random material in the master
>  key calculation than is allowed by the fixed-length Random value.
>
>I believe more justification than that is required for Proposed
>Standard.
>
>In particular, what I'd like to see is references to some application
>environments where the extension is desirable, and the rationale why it
>is desirable in that environment.
>
>Without a rationale for when the extension is useful, it is impossible
>for implementers to know when use of this extension is warranted or not.

The environment I described in the earlier thread is TLS with
Diffie-Hellman. I thought that saying that was sufficient, but I guess
it wasn't.

In Diffie-Hellman key establishment with static keys, even if the PRNG
of one side is bad, the resulting pre-master secret is still sound.
Neither side knows whether or not the PRNG of the other side is bad, so
each side wants to supply sufficient randomness for the master secret
even if the other side's PRNG is bad. If a side with a bad PRNG adds its
own input, it doesn't hurt the randomness of the result, but a side with
a good PRNG can bring up the amount of randomness.

I did not want to list this as the justification because there may be
other reasons to use the extension, and I don't want readers to think
that this is the only one. For example, future types of TLS key
establishment might have similar properties as static-static
Diffie-Hellman.

Does that help?

--Paul Hoffman, Director
--VPN Consortium