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

Michael Gray <mickgray@au1.ibm.com> Wed, 07 October 2009 06:05 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 D3DC23A6974 for <tls@core3.amsl.com>; Tue, 6 Oct 2009 23:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.579
X-Spam-Level:
X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, 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 T-FsmTqgfmAs for <tls@core3.amsl.com>; Tue, 6 Oct 2009 23:05:42 -0700 (PDT)
Received: from e23smtp06.au.ibm.com (e23smtp06.au.ibm.com [202.81.31.148]) by core3.amsl.com (Postfix) with ESMTP id 8D3BA3A6970 for <tls@ietf.org>; Tue, 6 Oct 2009 23:05:41 -0700 (PDT)
Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp06.au.ibm.com (8.14.3/8.13.1) with ESMTP id n9767Eai011277 for <tls@ietf.org>; Wed, 7 Oct 2009 17:07:14 +1100
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9764oM71614050 for <tls@ietf.org>; Wed, 7 Oct 2009 17:04:50 +1100
Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9767IDo023058 for <tls@ietf.org>; Wed, 7 Oct 2009 17:07:18 +1100
Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9767IgF023055; Wed, 7 Oct 2009 17:07:18 +1100
In-Reply-To: <p0624082ac6f1aeb26944@[10.20.30.158]>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: <OF1BAB75A9.BF74B7DA-ON4A257648.001D35CA-4A257648.00219A62@au1.ibm.com>
From: Michael Gray <mickgray@au1.ibm.com>
Date: Wed, 7 Oct 2009 16:07:02 +1000
X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 07/10/2009 17:13:29
MIME-Version: 1.0
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: base64
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 06:05:42 -0000

Paul Hoffman <paul.hoffman@vpnc.org> wrote on 07/10/2009 12:36:47 PM:

> At 11:33 AM +1000 10/7/09, Michael Gray wrote:
> >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?
>
> Either side MAY decide for many reasons to stop when they see the
> other sides's extension. I can add something to this effect to the next
draft.
>
> >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?
>
> It doesn't. This is really a different set of semantics than the
> previous draft. We realized that there was too many expectations
> being signalled, and decided to simplify.

IMHO the previous draft was easier from a Server configuration point of
view.  We want our Server configuration to be as simple and accommodating
as possible to minimize the number of configuration options our consuming
products need to deal with, which also simplifies things for our customers.
Thus in the previous draft version we needed  no Server configuration by
default in that the Server comes preconfigured with a default safe maximum
value.  Thus what ever the Client asks for, the Server will both accept and
provide, up until it’s maximum default configuration without needing a
configuration update from a customer.

We ended up with two optional configuration values for a Server: A optional
value for the Maximum amount of random data it will provide on request, and
an optional value for Minimum amount that the Server will accept from a
Client i.e. the Server MUST receive this minimal amount of additional PRF
input.

In this draft we could have the Server always respond with it’s Maximum
safe value or force the customer to always set a configuration value which
immediately causes customer pain.  Sending the maximum safe value seems an
over kill if the client does not need or want it; the client is after all
indicating how much it wants to add on it's side to the PRF and it seems
intuitive IMO for the Server to play ball and respond in kind.  If the
customer then makes the Server configuration value too small we could have
handshake fails with certain clients, reducing Server availability, a
situation that will require problem determination to resolve, and related
customer annoyance.

Mick Gray
IBM

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