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

Simon Josefsson <simon@josefsson.org> Wed, 21 April 2010 22:52 UTC

Return-Path: <simon@josefsson.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 B17853A6A45; Wed, 21 Apr 2010 15:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 zzjsduGVKFtp; Wed, 21 Apr 2010 15:52:19 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 0348D3A6AB5; Wed, 21 Apr 2010 15:52:15 -0700 (PDT)
Received: from mocca (c80-216-24-99.bredband.comhem.se [80.216.24.99]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3LMpvk9009925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 Apr 2010 00:51:59 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <201004212205.o3LM5pwQ019241@fs4113.wdf.sap.corp> <p06240887c7f52b14f905@[10.20.30.158]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100421:ietf@ietf.org::Gc2ICoGqJZoR1vg5:0kwO
X-Hashcash: 1:22:100421:tls@ietf.org::6AeUbcGGMf9b0qIL:A9oP
X-Hashcash: 1:22:100421:paul.hoffman@vpnc.org::UuET4qDmD6XqYNoZ:4Y+3
X-Hashcash: 1:22:100421:mrex@sap.com::UXdGmLm8T42ZKXgZ:RDz5
Date: Thu, 22 Apr 2010 00:51:57 +0200
In-Reply-To: <p06240887c7f52b14f905@[10.20.30.158]> (Paul Hoffman's message of "Wed\, 21 Apr 2010 15\:29\:06 -0700")
Message-ID: <87fx2oxvua.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.95.3 at yxa-v
X-Virus-Status: Clean
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: Wed, 21 Apr 2010 22:52:19 -0000

Paul Hoffman <paul.hoffman@vpnc.org>; writes:

> At 12:05 AM +0200 4/22/10, Martin Rex wrote:
>>The IESG wrote:
>>>
>>> The IESG has received a request from an individual submitter to consider
>>> the following document:
>>>
>>> - 'Additional Random Extension to TLS '
>>>    <draft-hoffman-tls-additional-random-ext-01.txt> as a Proposed Standard
>>
>>
>>I'm somewhat confused to see a Last Call for this proposal.
>>
>>We had a discussion on this document on the TLS WG mailing list and
>>determined that this proposal is completely unable to achieve
>>the stated goal.  This extension is completely bogus.
>
> You came to that conclusion; many other folks disagreed. You stated
> that you thought it was not useful in some environments, namely with
> RSA authentication where the client has a broken PRNG. If that is the
> only environment you care about, then this extension is not
> useful. TLS is used in many other environments, of course.

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.

/Simon