Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt

Michael Gray <mickgray@au1.ibm.com> Wed, 07 October 2009 01:32 UTC

Return-Path: <mickgray@au1.ibm.com>
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 590F53A67EC for <tls@core3.amsl.com>; Tue, 6 Oct 2009 18:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2RwyXndfZTO4 for <tls@core3.amsl.com>; Tue, 6 Oct 2009 18:32:48 -0700 (PDT)
Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by core3.amsl.com (Postfix) with ESMTP id 3FA113A6782 for <tls@ietf.org>; Tue, 6 Oct 2009 18:32:47 -0700 (PDT)
Received: from d23relay02.au.ibm.com (d23relay02.au.ibm.com [202.81.31.244]) by e23smtp03.au.ibm.com (8.14.3/8.13.1) with ESMTP id n971Vp7f031706 for <tls@ietf.org>; Wed, 7 Oct 2009 12:31:51 +1100
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay02.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n971YLlq610536 for <tls@ietf.org>; Wed, 7 Oct 2009 12:34:22 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n971YLNo028956 for <tls@ietf.org>; Wed, 7 Oct 2009 12:34:21 +1100
Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av03.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n971YLKV028953; Wed, 7 Oct 2009 12:34:21 +1100
In-Reply-To: <p06240826c6f18d5f99ae@[10.20.30.158]>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: <OFF58EEF76.F1F1430F-ON4A257648.000849F8-4A257648.000896D8@au1.ibm.com>
From: Michael Gray <mickgray@au1.ibm.com>
Date: Wed, 7 Oct 2009 11:33:49 +1000
X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 07/10/2009 12:40:31
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Cc: tls@ietf.org
Subject: Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt
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, 07 Oct 2009 01:32:49 -0000

Paul Hoffman <paul.hoffman@vpnc.org>; wrote on 07/10/2009 10:16:38 AM:

> At 9:35 AM +1000 10/7/09, Michael Gray wrote:
> >Comparing this with draft-rescorla-tls-extended-random-02.txt I see the
> >requirement for the size of Server response is missing and thus
undefined.
>
> Correct. Both sides send arbitrary-length values.
>
> >From 3.1 in the above we have:
> >
> >   If the server wishes to use the extended randomness feature, it MUST
> >   send its own "extended_random" extension with an
> >   extended_random_value equal in length to the client's
> >   extended_random_value
> >
> >Additionally, I think some limitation of the size/amount of data that
can
> >be requested from a server is needed as large sizes could pose an attack
on
> >a server by exhausting the entropy pool and/or causing server
performance
> >degradation.
>
> In this proposal, server never "requests" any particular size. The
> client offers its value in the extended_random extension, and the
> server offers its value in the reply.
>
> >  Our prototype implementation allows servers to ignore or
> >respond with error, depending on configuration, requests from clients
that
> >are larger than 256 octets.
>
> ...which is a good reason why we abandoned the "request a size"
semantics.

In this case should be this draft also indicate that the client MAY
generate a fatal "handshake_failure" alert in the event that the Server
provides insufficient data?

Would this again be true for the Server, if a Client sends insufficient
data? i.e. A Server MAY generate a fatal "handshake_failure" alert in the
event that the Client provides insufficient data?

Additionally, can the Server use the Client size as an indication of how
much the Server should send? else how does the Client convey a
minimum/desired requirement information to a Server?


Mick Gray
IBM

>
> --Paul Hoffman, Director
> --VPN Consortium